On Tue, 2010-04-13 at 10:31 +0200, ext Kalle Valo wrote: > Juuso Oikarinen <juuso.oikarinen@xxxxxxxxx> writes: > > >> But we do not want to tie our hands to a simple timeout value because > >> that only applies to the very crude dynamic ps implementation we have > >> currently. What if, next year, we have an uber cool new power save > >> implementation in mac80211 which doesn't use the timeout value at all, > >> what do we do with the nl80211 timeout parameter then? Deprecate it? > > > > I agree that letting user-space configure a raw timeout is rather crude. > > But in my view the problem really is that we don't have that uber-cool > > power save feature of the future yet, and hence cannot fully take its > > needs into account. So apparently, until we do, we have to live without > > even the crude one? > > > > Or is it better to deprecate a semi-complex interface instead of a crude > > one, if even that does not meet all requirements of whats to come? > > But nl80211 is a user space interface and there are special rules for > that. Basically we need to support it a long time to avoid breaking > existing user space applications. If we add new features to nl80211 > which we will deprecate later on, it will soon become a mess and > difficult to maintain. That would create more work for the wireless > community and I would like to minimise the extra work, naturally :) > > If this would affect only a kernel internal API (like mac80211 driver > API), I would have no objections at all. That's always easy to change. > > >> I think power save control should happen outside nl80211. The problem > >> here is that we want to inform kernel about events (or states) in user > >> space (display turned off, user activity, voip call etc.). We need a > >> different interface for that, nl80211 is not suitable for this. Also > >> other subsystems than wireless would definitely benefit from this kind > >> of information. The interface might already exist (pm qos?) or we have > >> to create a new one, I haven't studied this that much. > > > > I looked into this slightly. I can see, that the mac80211 has support > > for a latency-wish from user-space, using pm_qos. This seems to affect > > only the dtim-period somehow (by the way, at least the wl1251 driver has > > an obvious bug about this - if the AP dtim is > 1 and user-space > > configures the latency properly, you can make the wl1251 miss broadcast > > traffic in PSM.) > > Thanks, I wrote down that wl1251 issue and I'll take a look at it > later on. > > >> I would recommend to see if the pm qos interface can be used to hint > >> mac80211 dynamic ps enough so that you would get similar end result as > >> with the WE power timeout value. It should be possible, but I haven't > >> checked the code myself. > > > > The problem here is that the latency at least cannot be used in any > > simple and/or general way I can think of to control the dynamic PS > > timeout. > > Can't you do something like this: > > pm_qos >= 1000 -> timeout 0 ms (aka. full power save) > pm_qos <= 100 -> timeout 100 ms > pm_qos <= 50 -> timeout 300 ms > > That is, just some arbitrary numbers but which affect dynamic ps > timeout. I haven't thought about the numbers at all, but they actually > don't matter because it's easy to change them inside mac80211. Theoretically I could, but I'm pretty sure whatever values I would choose would be unacceptable by others, as they would be tuned for a specific use. Also, although AFAIK barely anyone uses the DTIM interval which is determined based on th pm_qos, adding arbitrary rules like this to the side risks breaking something for someone. -Juuso > > So we would still need to add some crude PS level stuff anyway, > > unless someone comes up with that uber-cool solution of tomorrow > > already today. > > > > I see there is fierce resistance, so I'll drop looking into this here. > > As far as I can see, the result of this is that anyone using linux > > wireless in their hand-held devices either cannot switch to nl80211 > > today or have to use nl80211 and wext simultaneously. > > If yoy need this right now, using wext for setting the timeout is the > fastest way. But it's ugly :/ > Ugly it is! -Juuso -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
