[ath9k-devel] [PATCHv4 2/3] mac80211: mesh power save doze scheduling

[Marco Porsch <marco@cozybit.com>]

Am 04.03.2013 21:25, schrieb Johannes Berg:
> On Mon, 2013-03-04 at 13:23 -0600, Seth Forshee wrote:
>
>> I've been looking at power save in mac80211 over the past few days with
>> an eye towards allowing multiple interface to be supported, as a result
>> of comments Johannes made at [1]. It seems like adding driver callbacks
>> for PS which are specific to the interface type is contrary to this
>> goal.
>
> Yeah, this is a concern. I didn't really stand in the way of doing mesh
> powersave though, and it seemed that the new interface here would
> actually be somewhat suitable, since for mesh any kind of powersave code
> needs to know when to wake up/sleep. I would've liked to see less
> reliance on host timers directly in core mac80211 even for the going to
> sleep part though... basically I'm not sure for mesh just having PS
> state will cut it. For managed mode this is easy because it only needs
> to sync with a single AP, but for mesh that's a bit more complicated and
> I think the whole sync should stay in mac80211. In the general case,
> just having the TSF might not be enough, but that can be solved as
> needed.
>
>> The basic idea that's been forming on my mind is add PS states to vifs
>> and make the managed, mesh, etc. code manipulate vif PS states rather
>> than hw states. Then a PS module would manage the hw state based on the
>> aggregate of the vif states.
>
> Yeah, that about matches what I was thinking. But like I said above,
> while this is fairly simple for managed mode, at least as required
> today, it's clearly not as simple for mesh.
>
> For managed mode, we also assume that we can send packets while the
> device is sleeping, and the device will do the right thing to wake up
> for beacons from the AP etc. For mesh, there are many more wakeup
> sources, from what I can tell.

I also assume that the device deals with TX while sleeping.

The complete list of wakeup sources for mesh are:
- awake window after beacon and probe response TX
- authentication, peering, scanning procedures
- frame release in mesh peer service periods
- RX peer's beacons and DTIM multicasts (only in mesh light sleep mode)

>> I don't have a lot of the details worked out yet, and my knowledge of PS
>> in mesh networks (and of mesh network operation in general) is pretty
>> rudimentary at this point. But afaict any modes which support PS define
>> the same two hw states, awake and doze. I wonder whether we should
>> instead aim for a single interface into the driver for PS that's capable
>> of supporting all interface types.
>
> Such an interface would probably have to be the interface now defined
> for mesh, telling the device when to wake up and go to sleep? But this
> interface is rather inefficient for most chipsets...

I guess the case of a single managed mode vif should be handled 
separately to benefit from the HW support most devices provide.

--Marco