[PATCH rtw-next] wifi: rtw88: usb: send broadcast/multicast via the AC queues

[PATCH rtw-next] wifi: rtw88: usb: send broadcast/multicast via the AC queues

[Mehmet Fide]

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

In AP mode every broadcast and multicast data frame is routed to
TX_DESC_QSEL_HIGH, the after-DTIM queue. The firmware drains that
queue at beacon pace, roughly a dozen frames per second, while a
single associated client's mDNS/SSDP chatter alone exceeds that.
The excess accumulates inside the chip until the shared TX page
pool is exhausted; measured on RTL8822BU, 14 of 1803 pages were
left. From that point every host-sourced frame queues behind the
backlog: authentication responses reach the air seconds after the
client has given up, so no station can associate anymore, and the
beacon reserved-page download fails the BCN_VALID poll ("error
beacon valid") because it needs pages from the same exhausted pool.
The AP keeps beaconing throughout, so from the outside this looks
like a silent receive stall, and only a reboot recovers.

On USB the HIGH, MGMT, BEACON and H2C queues additionally share one
bulk-out endpoint, so the jam also head-of-line blocks firmware
commands.

Route broadcast/multicast data through the regular AC queues
instead. They then leave at line rate and the page pool never
fills. The trade-off is that stations in power save may miss
multicast that the after-DTIM queue would have buffered for them;
at the chatter rates that trigger the jam those frames were being
dropped anyway.

On a bench AP (RTL8822BU, USB2, 20 MHz, WPA2, hostapd, a Windows
client driven through disconnect/reconnect cycles): reconnects fail
0/5 before this change and pass 5/5 with it, with the page pool
staying healthy and no beacon errors logged.

Signed-off-by: Mehmet Fide <mehmet.fide@screeningeagle.com>
---
 drivers/net/wireless/realtek/rtw88/usb.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtw88/usb.c b/drivers/net/wireless/realtek/rtw88/usb.c
index 64e1c3420..f528fe0f2 100644
--- a/drivers/net/wireless/realtek/rtw88/usb.c
+++ b/drivers/net/wireless/realtek/rtw88/usb.c
@@ -565,9 +565,6 @@ static u8 rtw_usb_tx_queue_mapping_to_qsel(struct sk_buff *skb)
 
 	if (unlikely(ieee80211_is_mgmt(fc) || ieee80211_is_ctl(fc)))
 		qsel = TX_DESC_QSEL_MGMT;
-	else if (is_broadcast_ether_addr(hdr->addr1) ||
-		 is_multicast_ether_addr(hdr->addr1))
-		qsel = TX_DESC_QSEL_HIGH;
 	else if (skb_get_queue_mapping(skb) <= IEEE80211_AC_BK)
 		qsel = skb->priority;
 	else
-- 
2.54.0

Re: [PATCH rtw-next] wifi: rtw88: usb: send broadcast/multicast via the AC queues

[Bitterblue Smith]

On 13/08/2026 16:18, Mehmet Fide wrote:
> From: Mehmet Fide <mehmet.fide@screeningeagle.com>
> 
> In AP mode every broadcast and multicast data frame is routed to
> TX_DESC_QSEL_HIGH, the after-DTIM queue. The firmware drains that
> queue at beacon pace, roughly a dozen frames per second, while a
> single associated client's mDNS/SSDP chatter alone exceeds that.
> The excess accumulates inside the chip until the shared TX page
> pool is exhausted; measured on RTL8822BU, 14 of 1803 pages were
> left. From that point every host-sourced frame queues behind the
> backlog: authentication responses reach the air seconds after the
> client has given up, so no station can associate anymore, and the
> beacon reserved-page download fails the BCN_VALID poll ("error
> beacon valid") because it needs pages from the same exhausted pool.
> The AP keeps beaconing throughout, so from the outside this looks
> like a silent receive stall, and only a reboot recovers.
> 
> On USB the HIGH, MGMT, BEACON and H2C queues additionally share one
> bulk-out endpoint, so the jam also head-of-line blocks firmware
> commands.
> 
> Route broadcast/multicast data through the regular AC queues
> instead. They then leave at line rate and the page pool never
> fills. The trade-off is that stations in power save may miss
> multicast that the after-DTIM queue would have buffered for them;
> at the chatter rates that trigger the jam those frames were being
> dropped anyway.
> 
> On a bench AP (RTL8822BU, USB2, 20 MHz, WPA2, hostapd, a Windows
> client driven through disconnect/reconnect cycles): reconnects fail
> 0/5 before this change and pass 5/5 with it, with the page pool
> staying healthy and no beacon errors logged.
> 
> Signed-off-by: Mehmet Fide <mehmet.fide@screeningeagle.com>

I wonder if you can reproduce this problem with kernel 6.5? It looks
like commit 076f786a0ae1 ("wifi: rtw88: Fix AP mode incorrect DTIM
behavior") from 6.5 was supposed to fix the exact same problem.
This is also the commit which introduced the code you are now removing.

> ---
>  drivers/net/wireless/realtek/rtw88/usb.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtw88/usb.c b/drivers/net/wireless/realtek/rtw88/usb.c
> index 64e1c3420..f528fe0f2 100644
> --- a/drivers/net/wireless/realtek/rtw88/usb.c
> +++ b/drivers/net/wireless/realtek/rtw88/usb.c
> @@ -565,9 +565,6 @@ static u8 rtw_usb_tx_queue_mapping_to_qsel(struct sk_buff *skb)
>  
>  	if (unlikely(ieee80211_is_mgmt(fc) || ieee80211_is_ctl(fc)))
>  		qsel = TX_DESC_QSEL_MGMT;
> -	else if (is_broadcast_ether_addr(hdr->addr1) ||
> -		 is_multicast_ether_addr(hdr->addr1))
> -		qsel = TX_DESC_QSEL_HIGH;
>  	else if (skb_get_queue_mapping(skb) <= IEEE80211_AC_BK)
>  		qsel = skb->priority;
>  	else

Re: [PATCH rtw-next] wifi: rtw88: usb: send broadcast/multicast via the AC queues

[Mehmet Fide]

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

Hello Bitterblue,

> I wonder if you can reproduce this problem with kernel 6.5? It looks
> like commit 076f786a0ae1 ("wifi: rtw88: Fix AP mode incorrect DTIM
> behavior") from 6.5 was supposed to fix the exact same problem.
> This is also the commit which introduced the code you are now removing.

Thanks, I was not aware of that commit, and you are right that my patch
reverts exactly the usb.c hunk of it; the MORE_DATA and HGQMD parts
stay. I will say that in the commit message in a v2.

I did not run 6.5 and cannot easily on this hardware, the board support
we run starts at 6.12. I do not think it would add information though:
the code from 076f786a0ae1 is unchanged between 6.5 and the 6.12.103 I
tested, and it was demonstrably engaged while the AP was wedged. In a
register snapshot taken in that state REG_TCR reads 0x00303030, so
BIT_TCR_UPDATE_HGQMD was set. Still, the high queue drained at about 14
frames a second, roughly 3 frames per DTIM at beacon interval 100 and
dtim_period 2, measured over minutes from the URB submit/complete
counters, while several hundred frames sat queued. So at least on
RTL8822BU the burst fetch does not happen even with that fix active.
RTL8821CU behaves the same, measured today on the same bench with only
the dongle swapped: stock fails the reconnect test 0/3 with the "error
beacon valid" messages appearing, and passes 5/5 with none once the bmc
routing is reverted. RTL8822BU is 0/5 stock and 10/10 with the revert.

I also think the two problems are different. 076f786a0ae1 addresses the
hardware fetching one buffered packet per DTIM instead of the whole
burst. What we hit is sustained inflow above any DTIM-paced outflow: on
USB the high queue shares the single bulk-out endpoint and the page
pool with the beacon and H2C queues, so once the pool is exhausted
(measured: 14 of 1803 pages left) the beacon reserved-page download
fails ("error beacon valid"), the TIM stops updating, and the firmware
never releases the burst, which closes the loop and no station can
associate again.

If you would rather keep the after-DTIM delivery for stations in power
save, I am happy to test an alternative, for example routing bmc to the
high queue only while a station is actually in PS, or a depth cap on
the high queue. On this hardware the plain AC-queue routing is what I
could verify.

Thanks,
Mehmet