On Thu, 2009-01-22 at 13:45 +0200, Kalle Valo wrote: > Here's my suggestion for how to implement ps-poll in mac80211. Also > this fixes the case when dynamic_ps_timeout is zero. Looks good to me. > I decided to use ps-polling when dynamic_ps_timeout is zero. If > userspace sets timeout to zero, it means that it's ready to sacrifice > throughput over power consumption. But in case there throughput is > more, userspace can set timeout to a non-zero value and null frame > wakeup is used instead, throughput is higher but power consumption > also increases. Not a bad choice. > Most probably this patchset breaks ath9k multicast handling. I > recommend ath9k to try do multicast tim bit handling in hardware, I > would really assume that to be possible. But if that's really > impossible, then it can be done in the driver. But having support for > waking up multicast tim bits in mac80211 is unreliable and complicated > the implementation, I just recommend dropping it. I agree, we should push this as close to the device as possible. mac80211 has to defer to a workqueue which adds latency, while if this really needs to be done in software the driver can do it much faster because it doesn't necessarily have any generic workqueue requirement and can possibly even wake the hardware in irq context. > Open question is that should power save be disabled whenever mac80211 > is ps-polling the frames. For example, p54/stlc45xx does not require to > disable power save in that case, it just stays awake long enough to > receive the data frame from the AP. So I did not disable power save > mode in this case, but I would like to hear comments what other > hardware needs. I just checked, Broadcom's hardware/firmware definitely requires doing this in software. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
