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

On 13/08/2026 21:50, Mehmet Fide wrote:
> From: Mehmet Fide <[email protected]>
> 
> Hello Bitterblue,
> 
>> Could you check what the official driver is doing in the same situation?
>>
>> https://github.com/morrownr/88x2bu-20210702
> 
> Good timing, we had already done exactly that comparison before your
> mail arrived. That driver was our working reference on the same bench
> throughout the investigation (5/5 reconnect cycles where in-tree fails
> 0/5), and we went through its AP transmit path to understand why it is
> immune. It handles this quite differently, in five ways:
> 
> 1. bmc frames are buffered only while a station is actually dozing
>    (sta_dz_bitmap check in core/rtw_xmit.c, rtw_xmit_ap_enqueue). With
>    no sleeper present they leave immediately through the normal AC
>    path, which is what my patch restores for rtw88.
> 
> 2. The buffering happens in software (the bmc sta's sleep_q), not in
>    the hardware high queue. The hardware HIQ receives at most one DTIM
>    burst at a time (chk_bmc_sleepq_hdl), so it can never accumulate
>    into the page pool the way rtw88's standing high queue does.
> 
> 3. Even then, a filter decides what may ride the HIQ at all. The
>    default (rtw_hiq_filter=1, "allow special") lets only ARP, EAPOL and
>    DHCP through; mDNS/SSDP chatter never enters the high queue. The
>    rest of the buffered frames go out through the normal queues when
>    the burst is released.
> 
> 4. The driver owns the TIM bit itself: it sets it when it starts
>    buffering, pushes the updated beacon, and clears it only after both
>    the software queue and the hardware HIQ are empty, polled through
>    HW_VAR_CHK_HI_QUEUE_EMPTY. It does not depend on a beacon download
>    whose pages come from the same pool the backlog is exhausting.
> 
> 5. MORE_DATA is set on every burst frame except the last one, which
>    carries 0 and terminates the burst. rtw88 sets it on every high
>    queue frame including the last. That may be part of why I measured
>    the burst fetch not happening here even with BIT_TCR_UPDATE_HGQMD
>    set: the hardware never sees the end marker the vendor code
>    provides.
> 
> So the field-proven driver never routes bulk multicast through the high
> queue either, sleeper or not; the high queue is a small, filtered,
> explicitly terminated DTIM burst buffer for it, not a transport path.
> 
> Given that, I still think routing bmc through the AC queues is the
> right minimal fix for rtw88 USB. If you want to keep buffered delivery
> for dozing stations I am happy to work on the fuller shape, meaning PS
> tracking plus a software staging queue released at DTIM, but that is a
> much bigger change and the current behavior is a hard AP breakage.
> 
> Thanks,
> Mehmet

I don't know enough to have an opinion on this.

Shouldn't mac80211 handle the buffering already?