Hi,
When using HW_PS and running Downlink only traffic like UDP-RX, mac80211
has the mechanism to not to enter power-save (postpone the dynamic ps
timer).
But if we are already in power-save it continues to stay in PS
and retrieves the frames, for large traffic this is not acceptable.
The standard doesn't say anything, its left to vendor to implement their
own mechanism.
I have the below questions
1) Are any other vendors seeing this issue?
2) Are they using proprietary algorithms to solve this,
implemented in their HW/FW?
3) If yes, how are they keeping the mac80211 and FW FSM in sync,
as the driver cannot request/indicate the power save state to mac80211.
(no feedback path).
IMHO,
a) we should implemented a feedback path, where the vendor
can implement proprietary mechanism to handle this and inform/request
mac80211 for a specific power save state.
b) mac80211 just conveys the user/system preferences to the driver
and driver handles the FSM on when to enter/exit PS? (true HW_PS).
Any suggestions/comments?
--
Thanks,
Regards,
Chaitanya T K.
On Fri, Apr 8, 2016 at 1:37 AM, Johannes Berg <[email protected]> wrote:
> On Thu, 2016-04-07 at 18:31 +0530, Krishna Chaitanya wrote:
>> Hi,
>>
>> When using HW_PS and running Downlink only traffic like UDP-RX,
>> mac80211 has the mechanism to not to enter power-save (postpone the
>> dynamic ps timer).
>>
>> But if we are already in power-save it continues to stay in PS
>> and retrieves the frames, for large traffic this is not acceptable.
>>
>> The standard doesn't say anything, its left to vendor to implement
>> their own mechanism.
>>
>> I have the below questions
>>
>> 1) Are any other vendors seeing this issue?
>
> No. Nobody else really relies on the mac80211 powersave any more.
>
>> 2) Are they using proprietary algorithms to solve this,
>> implemented in their HW/FW?
>
> Yes. "Proprietary" is such a big word.
>
>> 3) If yes, how are they keeping the mac80211 and FW FSM in sync,
>> as the driver cannot request/indicate the power save state to
>> mac80211.
>> (no feedback path).
>
> No need, don't use the mac80211 implementation! Tell mac80211 you
> implement PS and DYNAMIC_PS, and it will not do anything whatsoever.
I have forgotten abut disabling DYNAMIC_PS flag, thanks, Will try that.
>> IMHO,
>>
>> a) we should implemented a feedback path, where the vendor
>> can implement proprietary mechanism to handle this and inform/request
>> mac80211 for a specific power save state.
>
> No.
>
>> b) mac80211 just conveys the user/system preferences to the driver
>> and driver handles the FSM on when to enter/exit PS? (true HW_PS).
>>
> Done when you have PS and DYNAMIC_PS advertised to mac80211.
>
> The mac80211 powersave code is pretty much beyond salvaging anyway.
>
> What really should happen is that there should be some kind of library
> functionality that drivers that need host powersave management can hook
> into, *per interface*, and then do the right thing.
Agree, this gives devices more control, with common code implemented
by mac80211.
> Then eventually we can remove all the powersave handling code from
> mac80211, it's seriously broken anyway (doesn't support more than one
> virtual interface, has problems like you describe above, etc.)
On Thu, 2016-04-07 at 18:31 +0530, Krishna Chaitanya wrote:
> Hi,
>
> When using HW_PS and running Downlink only traffic like UDP-RX,
> mac80211 has the mechanism to not to enter power-save (postpone the
> dynamic ps timer).
>
> But if we are already in power-save it continues to stay in PS
> and retrieves the frames, for large traffic this is not acceptable.
>
> The standard doesn't say anything, its left to vendor to implement
> their own mechanism.
>
> I have the below questions
>
> 1) Are any other vendors seeing this issue?
No. Nobody else really relies on the mac80211 powersave any more.
> 2) Are they using proprietary algorithms to solve this,
> implemented in their HW/FW?
Yes. "Proprietary" is such a big word.
> 3) If yes, how are they keeping the mac80211 and FW FSM in sync,
> as the driver cannot request/indicate the power save state to
> mac80211.
> (no feedback path).
No need, don't use the mac80211 implementation! Tell mac80211 you
implement PS and DYNAMIC_PS, and it will not do anything whatsoever.
> IMHO,
>
> a) we should implemented a feedback path, where the vendor
> can implement proprietary mechanism to handle this and inform/request
> mac80211 for a specific power save state.
No.
> b) mac80211 just conveys the user/system preferences to the driver
> and driver handles the FSM on when to enter/exit PS? (true HW_PS).
>
Done when you have PS and DYNAMIC_PS advertised to mac80211.
The mac80211 powersave code is pretty much beyond salvaging anyway.
What really should happen is that there should be some kind of library
functionality that drivers that need host powersave management can hook
into, *per interface*, and then do the right thing.
Then eventually we can remove all the powersave handling code from
mac80211, it's seriously broken anyway (doesn't support more than one
virtual interface, has problems like you describe above, etc.)
johannes