Re: ieee80211_handle_wake_tx_queue and dynamic ps regression

From: Alexander Wetzel <alexander@wetzel-home.de>
To: Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
	linux-kernel@vger.kernel.org, johannes.berg@intel.com,
	Kalle Valo <kvalo@codeaurora.org>,
	linux-wireless@vger.kernel.org
Subject: Re: ieee80211_handle_wake_tx_queue and dynamic ps regression
Date: Tue, 10 Jan 2023 16:23:21 +0100	[thread overview]
Message-ID: <205fb221-f7ad-8f03-2c16-54dcbf5ecaf9@wetzel-home.de> (raw)
In-Reply-To: <cf5e9339-2511-1135-71da-a8342b264414@linaro.org>

On 10.01.23 15:47, Bryan O'Donoghue wrote:
> On 10/01/2023 12:44, Bryan O'Donoghue wrote:
>> + linux-wireless
>> On 10/01/2023 12:35, Bryan O'Donoghue wrote:
>>> commit a790cc3a4fad75048295571a350b95b87e022a5a 
>>> (wake_tx_queue-broken-23-08-01)
>>> Author: Alexander Wetzel <alexander@wetzel-home.de>
>>> Date:   Sun Oct 9 18:30:39 2022 +0200
>>>
>>>      wifi: mac80211: add wake_tx_queue callback to drivers
>>>
>>> is causing a regression with
>>>
>>> - CONF_PS = 1
>>> - CONF_DYNAMIC_PS = 0
>>> - ieee80211_handle_wake_tx_queue
>>>
>>> In this case we get stuck in a loop similar to this
>>>
>>> // IEEE80211_CONF_CHANGE_PS
>>> [   17.255480] wcn36xx: wcn36xx_change_ps/312 enable
>>> [   18.088835] ieee80211_tx_h_dynamic_ps/263 setting 
>>> IEEE80211_QUEUE_STOP_REASON_PS
>>> [   18.088906] ieee80211_handle_wake_tx_queue/334 entry
>>> [   18.091505] ieee80211_dynamic_ps_disable_work/2250 calling 
>>> ieee80211_hw_config()
>>> [   18.095370] ieee80211_handle_wake_tx_queue/338 wake_tx_push_queue
>>>
>>> // IEEE80211_CONF_CHANGE_PS
>>> [   18.102625] wcn36xx: wcn36xx_change_ps/312 disable
>>> [   18.107643] wake_tx_push_queue/303 entry
>>>
>>> // txq is stopped here reason == IEEE80211_QUEUE_STOP_REASON_PS
>>> [   18.107654] wake_tx_push_queue/311 q_stopped bitmask 0x00000002 
>>> IEEE80211_QUEUE_STOP_REASON_PS true
>>> [   18.107661] wake_tx_push_queue/324 exit
>>> [   18.107667] ieee80211_handle_wake_tx_queue/342 exit
>>> [   18.115560] ieee80211_handle_wake_tx_queue/334 entry
>>> [   18.139937] ieee80211_handle_wake_tx_queue/338 wake_tx_push_queue
>>> [   18.145163] wake_tx_push_queue/303 entry
>>> [   18.150016] ieee80211_dynamic_ps_disable_work/2252 completed 
>>> ieee80211_hw_config()
>>>
>>> // now we unset IEEE80211_QUEUE_STOP_REASON_PS but too late
>>> [   18.151145] wake_tx_push_queue/311 q_stopped bitmask 0x00000002 
>>> IEEE80211_QUEUE_STOP_REASON_PS true
>>> [   18.155263] ieee80211_dynamic_ps_disable_work/2254 clearing 
>>> IEEE80211_QUEUE_STOP_REASON_PS
>>> [   18.162531] wake_tx_push_queue/324 exit
>>> [   18.162548] ieee80211_handle_wake_tx_queue/342 exit
>>> [   18.183639] ieee80211_dynamic_ps_disable_work/2259 cleared 
>>> IEEE80211_QUEUE_STOP_REASON_PS
>>>
>>> // IEEE80211_CONF_CHANGE_PS runs again
>>> [   18.215487] wcn36xx: wcn36xx_change_ps/312 enable
>>>
>>> We get stuck in that loop. Packets getting transmitted is a rare 
>>> event, most are dropped.
> 

I'll need some time digest that... I report back once I get it.

> BTW I considered implementing a wcn36xx specific wake_tx callback - 
> which maybe should be done anyway.
> 
> I _don't_ see other drivers checking for q_stopped & 
> IEEE80211_QUEUE_STOP_REASON_PS
> 
> Should they be ?
> 

No, they should not.

My take is, that this is a bug in mac80211. I submitted patches to 
fixing that, they have just been accepted:

https://patchwork.kernel.org/project/linux-wireless/patch/20221230121850.218810-1-alexander@wetzel-home.de/

and

https://patchwork.kernel.org/project/linux-wireless/patch/20230106223141.98696-1-alexander@wetzel-home.de/

Can you test if these also help here?

> If they should check IEEE80211_QUEUE_STOP_REASON_PS, then right now, 
> they don't. If they shouldn't check IEEE80211_QUEUE_STOP_REASON_PS then 
> neither should the generic replacement ieee80211_handle_wake_tx_queue()
> 
> ---
> bod