Re: [PATCH rtw-next v3 1/3] wifi: rtw88: usb: bound what the driver feeds the after-DTIM queue

[Ping-Ke Shih <pkshih@realtek.com>]

Mehmet Fide <mehmet.fide@gmail.com> wrote:

> From: Mehmet Fide <mehmet.fide@screeningeagle.com>
> 
> Frames routed to the high queue are transmitted right after DTIM beacons
> only, inside the ATIM window, while they wait in the shared TX page pool.
> The driver puts no limit on how many it hands over, so as long as one
> station dozes, any sustained broadcast or multicast traffic outruns the
> drain and empties the pool: measured on an RTL8822BU AP with a single
> client in power save and ~40 frames/s of mDNS chatter, the free page
> count at 0x240 goes from 1803 to 16 in about 100 seconds and stays there
> for as long as the traffic lasts. From that point every other transmit
> queues behind the backlog, authentication responses arrive too late for
> anyone to join, and the reserved page download fails ("error beacon
> valid"). The AP keeps beaconing and only a reboot recovers.
> 
> Feed the high queue through a small budget that refills below the
> measured drain rate (about 3 frames per DTIM, ~15/s at dtim_period 2 on
> the default 2 TU ATIM window); whatever exceeds the budget leaves on its
> access category queue right away. The high queue backlog is now bounded
> by the burst size under any load, so the page pool cannot run dry, at
> the price that a dozing station may miss part of a broadcast storm.
> 
> Signed-off-by: Mehmet Fide <mehmet.fide@screeningeagle.com>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>

3 patch(es) applied to rtw-next branch of rtw.git, thanks.

04cc8c59a3d7 wifi: rtw88: usb: bound what the driver feeds the after-DTIM queue
185971f1b4eb wifi: rtw88: usb: only let the frames a dozing station needs use the after-DTIM queue
cf8b516f6765 wifi: rtw88: widen the ATIM window while an AP interface is up

---
https://github.com/pkshih/rtw.git