RE: multicast traffic and ath9k

[Johannes Berg <johannes@sipsolutions.net>]

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