Re: Thoughts about mac80211 client PS implementation

[Kalle Valo <kalle.valo@nokia.com>]

Johannes Berg <johannes@sipsolutions.net> writes:

> On Wed, 2008-11-05 at 22:27 +0200, Kalle Valo wrote:
>> I'm working on implementing the "dynamic Power Save" (ie. PS enabled
>> after an idle period) feature to mac80211. Here are my current
>> thoughts:
>> 
>> First of all, I think we should enable CONF_PS only when associated.
>> So instead of directly calling hw_config() from
>> ieee80211_ioctl_siwpower() we should do that only when associated.
>> Otherwise we change it only after association or disassociation. This
>> means that we have to add a separate bit/variable for storing what
>> user has requested.
>
> Totally agreed.

Good :)

>> PS should be disabled while associated and running software scan, and
>> naturally re-enabled after the scan has finished. I assume hardware
>> scanning implementations are clever enough to disable PS when scanning
>> and we don't have to worry about that case.
>
> And on that too. And should there be a monitor flag that disables PS, so
> that we can "refcount" the PS bit in a way?

Sorry, I don't follow you here. What do you mean by a monitor flag?

>> The dynamic PS implementation is still a bit open issue for me. I have
>> been thinking something like that in tx.c frames will be queued if PS
>> is enabled, PS will be disabled in a workqueue by calling
>> ieee80211_hw_config() and only after that the queued frames are
>> transfered. So something similar as sta->ps_tx_buf does in AP mode. No
>> idea if this is feasible or not.
>
> Not sure I understand the dynamic PS yet. 

Basically the idea is to disable PS whenever we are transmitting (and
maybe also receiving, don't know yet) frames, but whenever there's a
long enough idle period PS would be enabled again. So in principle
this would be a compromise of low power consumption and low latency.

Naturally the idle period would be configurable with siwpower() and
whatever nl80211 equivalent we will have in future.

> Why would you queue up frames? To reduce the number of radio wakeups
> when TX traffic is low?

Just because I assume that invoke_tx_handlers() cannot sleep but
ieee80211_hw_config() sleeps. I didn't think of any other way to solve
this, but I haven't thought that much about this. What do you think?

-- 
Kalle Valo