mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mehmet Fide <mehmet.fide@gmail.com>
To: Ping-Ke Shih <pkshih@realtek.com>
Cc: Bitterblue Smith <rtl8821cerfe2@gmail.com>,
	linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
	Mehmet Fide <mehmet.fide@screeningeagle.com>
Subject: [PATCH rtw-next 0/2] wifi: rtw88: usb: keep bmc traffic from exhausting the TX page pool
Date: Wed,  2 Sep 2026 12:41:44 +0200	[thread overview]
Message-ID: <20260902104146.3853102-1-mehmet.fide@gmail.com> (raw)

From: Mehmet Fide <mehmet.fide@screeningeagle.com>

Hi Ping-Ke, Bitterblue,

this follows up on the discussion under the v3 routing patch [1]: with
that patch applied, a single dozing station is still enough to route all
broadcast and multicast traffic through the high queue, and since the
chip only drains that queue in the ATIM window after DTIM beacons while
the frames occupy the shared TX page pool, ordinary chatter empties the
pool and the AP stops accepting stations. Numbers and the ATIM window
experiment are in the thread [2]; the short version: at the default 2 TU
window the queue drains ~3 frames per DTIM, ~40 frames/s of mDNS takes
the pool from 1803 to 16 pages in about 100 s, and enlarging the window
to 4 TU or more makes the same storm harmless.

The series follows the order Ping-Ke suggested (bound first, then
filter):

Patch 1 caps how many frames the driver hands to the high queue with a
small token bucket set below the measured drain rate; the excess goes
out on the access category queue right away. This is the guarantee: the
pool stays healthy under any storm, including ARP/DHCP bursts.

Patch 2 admits only ARP, EAPOL and DHCP to the after-DTIM path, matching
the vendor driver's default high queue filter, so ordinary chatter never
reaches the beacon-paced queue and the budget is left for the frames a
sleeping station actually needs. At runtime the filter is evaluated
before a token is taken, so chatter does not consume the budget.

Not included: raising REG_ATIMWND. It would add drain capacity, but the
queue stays unbounded and a wider window costs every PS station awake
time after each DTIM; if the firmware is fine with a larger window on
the USB chips I can add it as a separate patch. The mac80211-side
buffering (IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING) needs a beacon-time
event; the firmware seems to have one (C2H_BCN_EARLY_RPT, used by the
vendor driver for TDLS), that is a follow-up once we know it works in AP
mode.

Tested on a Verdin AM62 AP with RTL8822BU (USB2, 20 MHz, WPA2, one
Windows client in power save), free page count read at 0x240, on top of
rtw-next with c710c7c2e038:
  - baseline (rtw-next as is), one client in power save, ~80 bmc frames/s
    generated on the AP: free pages 1803 -> 16 within 30 s and pinned for
    the whole storm, 18 "error beacon valid" / rsvd page failures, and
    after the storm three reconnect attempts failed (no association
    until the client left and the pool recovered ~90 s later)
  - patch 1 alone: 1803 pages throughout the same 180 s storm and a
    120 s DHCP-port storm, no beacon errors, ping over the existing link
    6/6, reconnects 3/3
  - patches 1+2: 1803 pages throughout both storms as well, no
    beacon errors, ping 6/6, reconnects 3/3; the filter keeps the
    budget for ARP/EAPOL/DHCP, so the DHCP-port storm is the case where
    the token bucket actually engages
  - join/ping cycling without power save (10 cycles): unchanged
  - with an iPhone (screen off) as the only associated station instead
    of the Windows client: baseline 1803 -> 17 in 30 s and three join
    attempts from a second device fail; with both patches 1803
    throughout and the second device joins 3/3
  - the same series on an RTL8821CU AP (i.MX8MP, PREEMPT_RT kernel,
    411 free pages when idle): baseline drops to 16 pages within 30 s
    and stays there, ping and three join attempts all fail; with the
    series the count stays at 411 through the multicast storm, dips to
    357 and recovers during the DHCP-port storm (the budget doing its
    job), ping 6/6 and joins 3/3. No atomic-context or lockdep
    complaints on the RT kernel.

[1] https://lore.kernel.org/linux-wireless/20260814053426.2473247-1-mehmet.fide@gmail.com/
[2] https://lore.kernel.org/linux-wireless/20260901091830.2506562-1-mehmet.fide@gmail.com/

Mehmet Fide (2):
  wifi: rtw88: usb: bound what the driver feeds the after-DTIM queue
  wifi: rtw88: usb: only let the frames a dozing station needs use the
    after-DTIM queue

 drivers/net/wireless/realtek/rtw88/usb.c | 82 +++++++++++++++++++++++-
 drivers/net/wireless/realtek/rtw88/usb.h |  5 ++
 2 files changed, 84 insertions(+), 3 deletions(-)

-- 
2.54.0


             reply	other threads:[~2026-09-02 10:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02 10:41 Mehmet Fide [this message]
2026-09-02 10:41 ` [PATCH rtw-next 1/2] wifi: rtw88: usb: bound what the driver feeds the after-DTIM queue Mehmet Fide
2026-09-02 10:41 ` [PATCH rtw-next 2/2] wifi: rtw88: usb: only let the frames a dozing station needs use " Mehmet Fide

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=20260902104146.3853102-1-mehmet.fide@gmail.com \
    --to=mehmet.fide@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mehmet.fide@screeningeagle.com \
    --cc=pkshih@realtek.com \
    --cc=rtl8821cerfe2@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®