On Fri, 2009-01-09 at 18:26 +0530, Vivek Natarajan wrote: > Johannes Berg wrote: > > > I'm inclined to ask you to remove that multicast checking from mac80211 > > and do it closer to the hardware, and simply require from the > > driver/hardware that mac80211 needs not do anything for multicast > > traffic. Mostly because I'm thinking that once we start relying on the > > software implementation in mac80211 the delay may be too large. > > I'm curious to know how this is implemented in other vendor drivers because > beacon processing is shared between the hw and sw. mc bit is processed in > the hw whereas tim bit and timestamp update need sw's help. That seems to be the case at least for p54 (stlc45xx). Not really sure about others. > Is the mc bit > checking done only on enabling power save? if set and mc packets are received, > how does it automatically go back to sleep and wouldn't there be any conflict > between mac80211 and the hw regarding power state since mac80211 is not aware > of the mc bit induced state change? I don't think there would be a conflict. mac80211's CONF_PS is always only "go to sleep if you can", so receiving multicast traffic would obviously imply not being able to go to sleep. When mac80211 then unsets the CONF_PS flag you'd just not go back to sleep after being awake for MC traffic. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
