multicast traffic and ath9k

multicast traffic and ath9k

[Johannes Berg]

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

Hi,

Does ath9k hardware really not check the multicast bit by itself? It
seems that we can't really be fast enough to wake up the hardware, so
the check for the MC bit is kinda useless, no?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

RE: multicast traffic and ath9k

[Vivek Natarajan]

Johannes Berg wrote:
> Does ath9k hardware really not check the multicast bit by itself? It
> seems that we can't really be fast enough to wake up the hardware, so
> the check for the MC bit is kinda useless, no?

There are two options in atheros drivers. One is hardware beacon processing
and the other is sw beacon processing. For some reason, sw beacon processing
is enabled by default, the performance is as expected and it has been working fine
for Windows implementation.

Some functions related to power save and beacon are beacon timestamp update,
verify tim bit and verify mc bit. The beacon timers have to be programmed correctly
to wake up for every beacon and process it for tim.  If the timer is slightly
out of sync, we my fail to receive the beacon.

The alternative is sw beacon processing using TIM_TIMER interrupt. This is a timer
which runs in the hw while majority of the hw is asleep. This generates an interrupt
for every beacon listen interval to wake up the chip and listen to beacon. We do not
go back to sleep unless we receive a beacon. Since there is no dependency on the
higher layers to update the beacon/sleep timers,  this implementation works fine in any
corner case. Hence, there is a need to process multicast bit in the software itself.

Vivek.

RE: multicast traffic and ath9k

[Johannes Berg]

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

On Fri, 2009-01-09 at 17:20 +0530, Vivek Natarajan wrote:

> There are two options in atheros drivers. One is hardware beacon processing
> and the other is sw beacon processing. For some reason, sw beacon processing
> is enabled by default, the performance is as expected and it has been working fine
> for Windows implementation.
> 
> Some functions related to power save and beacon are beacon timestamp update,
> verify tim bit and verify mc bit. The beacon timers have to be programmed correctly
> to wake up for every beacon and process it for tim.  If the timer is slightly
> out of sync, we my fail to receive the beacon.
> 
> The alternative is sw beacon processing using TIM_TIMER interrupt. This is a timer
> which runs in the hw while majority of the hw is asleep. This generates an interrupt
> for every beacon listen interval to wake up the chip and listen to beacon. We do not
> go back to sleep unless we receive a beacon. Since there is no dependency on the
> higher layers to update the beacon/sleep timers,  this implementation works fine in any
> corner case. Hence, there is a need to process multicast bit in the software itself.

But will the software actually be fast enough? I'm looking at the code,
and it'll defer processing the beacon to a workqueue, and only then wake
up the hardware. That means there's some latency, wouldn't we miss some
multicast frames then?

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.

Thoughts?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

RE: multicast traffic and ath9k

[Vivek Natarajan]

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. 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?

Vivek.

RE: multicast traffic and ath9k

[Johannes Berg]

[-- 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 --]

RE: multicast traffic and ath9k

[Vivek Natarajan]

Johannes Berg wrote:

> > 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.

How does the mac80211 know if the hw is receiving mc traffic or not and
unset the CONF_PS flag accordingly? Am I missing something basic here?

Maybe p54 (stlc45xx) has the answer for how it goes back to sleep after mc traffic.

Vivek.

Re: multicast traffic and ath9k

[Christian Lamparter]

On Friday 09 January 2009 14:59:25 Vivek Natarajan wrote:
> 
> Johannes Berg wrote:
> 
> > > 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.
> 
> How does the mac80211 know if the hw is receiving mc traffic or not and
> unset the CONF_PS flag accordingly? Am I missing something basic here?
> 
> Maybe p54 (stlc45xx) has the answer for how it goes back to sleep after mc traffic.

Well we have a flag to tell the firmware to do the following thing in client mode (while sleeping)

"If the PSM object's *_PSM_MCBC flag is set, and a beacon is received with the TIM's multicast traffic bit
set, [...] or the LMAC stays awake until the TIM's multicast traffic bit is cleared again from the beacon".

see:
STSW45X0C LMAC API: page 24 - LM_PSM_MCBC (~ P54_PSM_MCBC)

Regards,
	Chr

Re: multicast traffic and ath9k

[Kalle Valo]

Christian Lamparter <chunkeey@web.de> writes:

>> How does the mac80211 know if the hw is receiving mc traffic or not and
>> unset the CONF_PS flag accordingly? Am I missing something basic here?
>> 
>> Maybe p54 (stlc45xx) has the answer for how it goes back to sleep
>> after mc traffic.
>
> Well we have a flag to tell the firmware to do the following thing
> in client mode (while sleeping)
>
> "If the PSM object's *_PSM_MCBC flag is set, and a beacon is
> received with the TIM's multicast traffic bit set, [...] or the LMAC
> stays awake until the TIM's multicast traffic bit is cleared again
> from the beacon".

I doubt that LMAC stays awake until next beacon arrives, that would
increase the power consumption too much. Most probably it follows the
more data from the multicast frames and goes to sleep immeaditely
after it has received the last multicast frame.

-- 
Kalle Valo

Re: multicast traffic and ath9k

[Kalle Valo]

Vivek Natarajan <Vivek.Natarajan@Atheros.com> writes:

> Johannes Berg wrote:
>
>> > 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. 

Yes, there is no conflict. If stlc45xx firmware notices that multicast
tim bit is set, it will just stay awake long enough to receive all the
multicast frames, delivers them to the host and goes immediately back
to sleep.

>> When mac80211 then unsets the CONF_PS flag you'd just not go back
>> to sleep after being awake for MC traffic.
>
> How does the mac80211 know if the hw is receiving mc traffic or not and
> unset the CONF_PS flag accordingly? Am I missing something basic here?

Why would mac80211 need to unset CONF_PS? It can just receive the
multicast frames from the driver, it doesn't need to change the power
save state.

> Maybe p54 (stlc45xx) has the answer for how it goes back to sleep
> after mc traffic.

stlc45xx firmware handles multicast frames automatically.

-- 
Kalle Valo