On Wed, 2008-11-05 at 22:54 +0200, Kalle Valo wrote: > >> 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? Well if you add a monitor interface you may want to turn off PS, but I suppose you can just do that on the wlan0 interface you're associated on. > >> 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? But wouldn't that mean the other way around, i.e. whenever we transmit we disable it and then start a timer that re-enables it? Ah, you're thinking because TX handlers cannot sleep and the config callback may sleep? Hmm. I suppose then we'd have to defer the actual disable PS mode to a work struct. Maybe we don't want to disable PS for a single frame though, so how about this: * When a frame is transmitted, store the current frame counter (do we have one? we could add one) somewhere and arm a timer to fire N milliseconds in the future. * The timer checks that we have transmitted more than M frames in the time since it was started, and if so queues a work struct to disable PS. * The work function also sets a flags somewhere "dynamic PS has disabled PS" and arms another timer to fire after R millisecinds, that timer will queue work to enable PS again * the TX code, when the "dynamic PS has disabled PS" flag is set, mods the re-enable timer to be R milliseconds in the future again That way, M frames within a period of N milliseconds will disable PS, and it'll still disabled until R milliseconds elapse without traffic, and no timers are fired unless they are needed. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
