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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
