RE: multicast traffic and ath9k

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]