diff options
| author | Filip Bakreski <phial@phiality.com> | 2026-06-09 20:53:01 +1000 |
|---|---|---|
| committer | Felix Fietkau <nbd@nbd.name> | 2026-07-31 12:25:37 +0000 |
| commit | 5323d3e50c20ce53b9b393ef36b027d6cd1e6f11 (patch) | |
| tree | 24b933a66429b77ba3842afb4f0d6372e7d0244a /tools/perf/scripts/python | |
| parent | a92cd5dd792a63a5d8a72142835382d4edbe9933 (diff) | |
wifi: mt76: mt76u: use a threaded NAPI for the RX path
The USB RX path delivers frames to the stack via mt76_rx_complete() with
a NULL napi pointer, taking the netif_receive_skb_list() path, so it never
benefits from GRO -- unlike the DMA-based mt76 drivers, which pass a real
napi and use napi_gro_receive(). For bulk TCP traffic this is costly, as
every segment traverses the stack individually.
Service the MT_RXQ_MAIN queue from a threaded NAPI, reusing mt76_dev's
existing napi_dev and napi[] rather than adding new fields. The URB
completion handler schedules the napi; its poll drains the URBs, builds
the skbs, resubmits and delivers them through napi_gro_receive(). The MCU
queue stays on the existing RX worker. This enables GRO and moves RX
processing into its own kernel thread, parallelising the datapath.
On mt7921u at HE-MCS 11 (2x2, 80 MHz; fast.com, multiple streams) this
averages ~588 Mbit/s, versus ~424 Mbit/s when the same napi is instead
driven manually from the RX worker, and ~380 Mbit/s for the unmodified
driver.
Suggested-by: Lorenzo Bianconi <lorenzo@kernel.org>
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Filip Bakreski <phial@phiality.com>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20260609105301.196302-1-phial@phiality.com
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions
