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

[Mehmet Fide]

Hi Bitterblue,

You don't need real mDNS/SSDP - the driver keys the routing purely on the
destination address of the frame, so any multicast/broadcast the AP
transmits takes the same path. Real Windows/Apple clients get you there on
their own eventually (that is how we first hit it), but here is a
deterministic recipe.

Setup: RTL8822BU in AP mode (hostapd), DTIM 1, at least one station
associated so the BSS is live.

Generate the load from the AP host, egressing the wlan interface (use the
bridge/interface that carries the BSS, and your subnet's broadcast
address):

  # ~100 broadcast frames/s out of the AP
  ping -I wlan0 -b -i 0.01 192.168.42.255

Multicast works the same, e.g. "ping -I wlan0 -i 0.01 224.0.0.251", or a
UDP loop to the SSDP group 239.255.255.250:1900.

The firmware drains the HIGH queue at beacon pace - in my measurements
about a dozen frames/s at DTIM 1 - so ~100/s overruns it at once. The
shared TX page pool then bleeds down; I polled the free-page count
(register 0x240) and watched it fall from ~1800 to low double digits
within a minute. Once it bottoms out, new stations can no longer
associate (their auth/assoc responses queue behind the backlog) and
"error beacon valid" starts logging, because the reserved-page download
needs pages from the same exhausted pool. The AP keeps beaconing, so from
the air it looks like a silent receive stall; only a reboot recovers.

Two knobs confirm it is the queue and nothing else: raise DTIM (e.g. 3)
and the HIGH queue drains even slower, so the pool empties faster; drop
the ping rate below ~12/s and it never fills.

(This is on the v1 thread; the current revision is the v3 I sent as
"route bmc frames via the high queue only for DTIM delivery", which keeps
the after-DTIM path only for genuinely buffered multicast. The
reproduction above applies to both.)

Best regards,
Mehmet