Re: [PATCH] ath9k: limit multicast buffer hardware queue depth

[Felix Fietkau <nbd@openwrt.org>]

On 2013-06-05 4:09 PM, Jouni Malinen wrote:
> On Mon, Jun 03, 2013 at 07:31:54PM +0200, Felix Fietkau wrote:
>> The CAB (Content after Beacon) queue is used for beacon-triggered
>> transmission of buffered multicast frames. If lots of multicast frames
>> were buffered and this queue fills up, it drowns out all regular
>> traffic. To limit the damage that buffered traffic can do, try to limit
>> the queued data to becaon_interval / 8.
> 
> I'm not sure this would be compliant with the standard, but I guess
> something along these lines could be reasonable in some cases. However,
> it could be useful to take into account different DTIM Period parameters
> in the limit and instead of hardcoding this to one eight of the Beacon
> interval, the limit could be set based on Beacon interval * DTIM Period.
> Especially with large DTIM Period values, one eight of a Beacon interval
> may not be sufficient to handle even reasonable amount of group
> addressed frames.
Makes sense.

> Does this commit address More Data field updates when the driver decides
> to stop getting more frames without notifying mac80211 of this? The
> associated STAs would need to know when they can go back to sleep after
> the DTIM Beacon and the More Data field needs to be set to zero in the
> last frame the AP is sending out in the case this new limit is hit.
I'll make a new version of this patch that takes care of the More Data
field.

- Felix