From: Agustin Santiago Isasmendi <isasmendi.agus@gmail.com>
To: Navid Ghahremani <ghahramani.navid@gmail.com>,
Andrew Lunn <andrew+netdev@lunn.ch>
Cc: "David S . Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@kernel.org>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Junyang Han" <han.junyang@zte.com.cn>,
"Stefan Dösinger" <stefandoesinger@gmail.com>,
"Felix Fietkau" <nbd@nbd.name>,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-wireless@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: [RFC PATCH net-next 0/5] net: ethernet: zte: zx279128s: offload flows to and from WLAN interfaces
Date: Wed, 11 Nov 2026 15:44:21 +0100 [thread overview]
Message-ID: <20261111144426.1321237-1-isasmendi.agus@gmail.com> (raw)
Hi,
This series lets the ZX279128S switch driver offload flows whose ingress
or egress is a mac80211 AP interface, so that WiFi <-> WAN NAT traffic
no longer goes through the CPU's forwarding path. It is based on Navid
Ghahremani's v2 platform series, which adds the SoC and the driver:
https://lore.kernel.org/r/20261014072109.1759502-1-ghahramani.navid@gmail.com
The switch fabric has a second DMA engine (a ring pair the vendor
firmware uses for exactly this) and 16 "WLAN logical ports" that a
classifier entry can name as ingress or egress. Patch 3 adds the ring
and the ports; patch 4 binds a mac80211 interface to a port on first
use and accepts flows from the flowtable in both directions; patch 5
adds debugfs testing aids. Patches 1 and 2 describe the engine's
interrupt. The WLAN drivers are not touched: the frames the fabric
forwards are handed to the interface's normal transmit path, and the
frames of offloaded flows are picked up on the interface's ingress hook
and injected into the ring. Any mac80211 driver works.
This is not a WED-like path: the SoC has no block that chains the two
DMA engines, so the CPU still runs the WLAN driver's own transmit and
receive paths for these frames and moves the buffers between the rings
(no copies on the forwarded path). What it no longer does is the
bridge, routing, conntrack and NAT work, which is where the CPU time
went: CPU0 drops from 54 % to 13-25 % at the rates below. This is also
how the vendor firmware uses the engine.
Sent as RFC because:
- the base series is not merged yet, so this cannot be applied as is;
- a mac80211 AP interface cannot be put in an offload-enabled flowtable
today, since mac80211 answers -EOPNOTSUPP to TC_SETUP_FT and
nf_tables rejects the device. This series was tested with Felix
Fietkau's OpenWrt patch that ignores -EOPNOTSUPP there
(target/linux/generic/pending-6.18/
701-netfilter-nf_tables-ignore-EOPNOTSUPP-on-flowtable-d.patch).
Felix, do you plan to send that upstream? Without it, or something
like it, this feature cannot be enabled on mainline;
- design: binding a WLAN interface to a switch port from the ethernet
driver, through the interface's regular paths, keeps the WLAN drivers
out of it. I would like to know whether that is acceptable or
whether this should go through something closer to the mediatek WED
model.
The SoC has an unrelated problem under WiFi traffic: a PCIe read on one
CPU deadlocks against L2C-310 maintenance on the other, discussed in
https://lore.kernel.org/r/20261110153522.1620088-1-isasmendi.agus@gmail.com
This series was tested with both workarounds under discussion (a lock
around the PCIe reads, and the L2 cache off through the device tree)
with the same results.
Results on a ZTE ZXHN H3600 (MT7915 as AP, a phone as client, flowtable
with lan, wan and the AP interface, NAT on wan):
WAN -> WiFi download 393 Mbps offloaded, 109 Mbps on the CPU path
WiFi -> WAN upload 186 Mbps (capped by the upload server), 60
30 min soak 111 transfers, none failed, ring counters
consistent, kernel log clean
cold / warm boot gate 17/17 and 5/5 boots, offloaded traffic on
each, no hang
IPv6 flows are not offloaded, as in the base driver. The register
sequence and descriptor layout were reverse engineered from the
vendor's GPL kernel. Builds without warnings with W=1 (board config
and multi_v7_defconfig); checkpatch --strict, dt_binding_check and
dtbs_check are clean.
Agustin Santiago Isasmendi (5):
dt-bindings: net: zte,zx279128s-gmac: add the WLAN DMA interrupt
ARM: dts: zte: zx279128s: add the WLAN DMA interrupt
net: ethernet: zte: zx279128s: WLAN DMA ring and logical ports
net: ethernet: zte: zx279128s: offload flows to and from WLAN ports
net: ethernet: zte: zx279128s: debugfs knobs for the WLAN ring
.../bindings/net/zte,zx279128s-gmac.yaml | 20 +-
arch/arm/boot/dts/zte/zx279128s.dtsi | 4 +-
drivers/net/ethernet/zte/Kconfig | 5 +-
drivers/net/ethernet/zte/Makefile | 3 +-
drivers/net/ethernet/zte/zx279128s-eth.h | 124 ++-
drivers/net/ethernet/zte/zx279128s-main.c | 18 +-
drivers/net/ethernet/zte/zx279128s-ppe.c | 92 +-
drivers/net/ethernet/zte/zx279128s-wlan.c | 874 ++++++++++++++++++
8 files changed, 1114 insertions(+), 26 deletions(-)
create mode 100644 drivers/net/ethernet/zte/zx279128s-wlan.c
base-commit: 96b4b72978e9fcfdd74f809c159f26813995631b
--
2.30.2
next reply other threads:[~2026-11-11 14:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 14:44 Agustin Santiago Isasmendi [this message]
2026-11-11 14:44 ` [RFC PATCH net-next 1/5] dt-bindings: net: zte,zx279128s-gmac: add the WLAN DMA interrupt Agustin Santiago Isasmendi
2026-11-11 14:44 ` [RFC PATCH net-next 2/5] ARM: dts: zte: zx279128s: " Agustin Santiago Isasmendi
2026-11-11 14:44 ` [RFC PATCH net-next 3/5] net: ethernet: zte: zx279128s: WLAN DMA ring and logical ports Agustin Santiago Isasmendi
2026-11-11 14:44 ` [RFC PATCH net-next 4/5] net: ethernet: zte: zx279128s: offload flows to and from WLAN ports Agustin Santiago Isasmendi
2026-11-11 14:44 ` [RFC PATCH net-next 5/5] net: ethernet: zte: zx279128s: debugfs knobs for the WLAN ring Agustin Santiago Isasmendi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261111144426.1321237-1-isasmendi.agus@gmail.com \
--to=isasmendi.agus@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@kernel.org \
--cc=ghahramani.navid@gmail.com \
--cc=han.junyang@zte.com.cn \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=nbd@nbd.name \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=robh@kernel.org \
--cc=stefandoesinger@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®