On Mon, Sep 19, 2011 at 6:41 PM, Kalle Valo <kvalo@xxxxxxxxxx> wrote: > Luciano Coelho <coelho@xxxxxx> writes: > >> On Sun, 2011-09-18 at 15:03 +0300, Eliad Peller wrote: >>> In some cases the driver might want to change the >>> default dynamic ps timeout (e.g. coex activity adds >>> latency to the rx/tx path, which might result in >>> redundant psm entrance). >>> >>> Introduce a new ieee80211_set_dyn_ps_timeout() function >>> to let low-level drivers change the default timeout. >>> >>> Signed-off-by: Eliad Peller <eliad@xxxxxxxxxx> >>> --- >> >> >> Let's see what Johannes is going to say about this change in mac80211, >> but IIRC this timeout used to exist with WEXT, but it was not >> implemented in nl80211. We (at Nokia, probably Juuso) tried to >> implement it a long time ago, but after some discussions with Johannes, >> it was decided that this value wouldn't be settable from userspace at >> least. I don't know if it was considered setting it from the driver >> side, though. > > My first thought about this was: "This is so wrong." :) > yeah, mine too :) > So we now have the wext interface for setting the timeout, we also use > the PM QoS framework to set it and with this patch even from drivers > can set it. That's quite a mess. > > What are these "some cases" referred above? I'm just worried that this > is just a workaround for an issue and adding the extra complexity is a > high cost just to workaround something. Please remember that mac80211 > power save is a big problem already now. > AFAIU from the coex guys, the scenario is something like this: upon coex activity, the fw might delay its rx and tx paths. this means that the fw might get a frame within the 100ms of the dyn ps, but delay its processing and pass it up to the driver only later. this will cause redundant psm enter (after 100ms) and psm exit (after the fw passed the packet). i'm not sure about the exact effect during coex operation, but eventually these psm enter/exit affect the throughput. another point here, is that during a specific period (during auto_mode on), there might or might not be coex activity. thus, we can't just disable dyn_ps, as it will hurt throughput (when there is no coex activity). bottom line - i'm not sure about all the details, but according to their tests - it does improve the throughput. (i can try getting better details if you have additional questions) Eliad. -- 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
