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

[Bitterblue Smith <rtl8821cerfe2@gmail.com>]

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