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

On 13/08/2026 18:07, Bitterblue Smith wrote:
> On 13/08/2026 16:18, Mehmet Fide wrote:
>> From: Mehmet Fide <[email protected]>
>>
>> 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 <[email protected]>
> 
> 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.
> 

By the way, do you know an easy way to generate mDNS/SSDP chatter,
to reproduce this bug?

>> ---
>>  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
>