On Mon, 2009-11-09 at 22:09 +0100, Jan Kiszka wrote: > Could someone briefly explain how the firmware is supposed to handle > this case? By scanning outgoing frames for multicast addresses? Should > the DTIM condition be detected and reported (via beacon) only by the > firmware, or would the driver be involved to some degree? If we handle > this transparently in the firmware, I guess that it would have to buffer > not only a single multicast frame, right? Do we have enough memory for > this on the chip? The driver is always involved in some way, cf. IEEE80211_TX_CTL_SEND_AFTER_DTIM and IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING in mac80211.h As to what the right thing with ar9170 is -- I don't know. Maybe the firmware could buffer a few frames, and the driver can push the remaining frames down once the device tells it the beacon was sent. Or maybe it's OK, although not perfect, if we simply send the frames once the device says the beacon was sent... I've never understood how the QoS implementation in this thing works, and that's kinda related. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
