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,

> Shouldn't mac80211 handle the buffering already?

It handles the decision already, and that turns out to be the key.
For bmc frames in AP mode, ieee80211_tx_h_multicast_ps_buf() sets
IEEE80211_TX_CTL_SEND_AFTER_DTIM only while at least one station is
actually dozing, and then either buffers the frame itself, when the
driver declares IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING and pulls
them with ieee80211_get_buffered_bc() after each DTIM beacon, or
passes it to the driver with the flag set and expects the device to
do the after-DTIM release.

rtw88 is in the second group, but it never looks at the flag: it
routes every bmc frame through the high queue whether anybody sleeps
or not, which is what lets the backlog build up. The full host
buffering model does not really fit rtw88 USB, the beacons come from
the firmware and there is no per-beacon event to pull buffered frames
on. Honoring the flag fits, and it is a one line change: flagged
frames keep the high queue with the MORE_DATA/HGQMD handling from
076f786a0ae1, everything else goes out through the AC queues at line
rate. The vendor driver gates on the same condition, a station
actually being in PS, just with its own bookkeeping.

I have sent a v2 doing exactly that. It passes the same reconnect
test that fails on stock (RTL8822BU 10/10 with 4/4 pings on every
cycle, first association included). The dozing-station path keeps the
existing high queue code unchanged; I could not exercise a client in
powersave on this bench yet and will follow up with that measurement
next week.

Thanks,
Mehmet