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

[Mehmet Fide <mehmet.fide@gmail.com>]

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

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