[23.05]: kernel: mac80211: mac80211 stops pushing data and packet rate drops to 0 with large buffer sizes

[morse-sophronia]

I am facing an issue, where my wireless driver is unable to push data with large buffer sizes and packet rate drops to 0.

With more investigation I see that there is an issue with the “wake_tx_queue " ieee80211_ops callback ieee80211_handle_wake_tx_queue in Openwrt.

Originally mac80211 v6.1.24 brought in the model, where the driver pulls data frames from the mac80211 queue instead of letting mac80211 push them via drv_tx(), if the driver indicates that it uses this model by implementing the .wake_tx_queue driver operation. This makes “.wake_tx_queue” an optional callback in v6.1.24.

Whereas, since openwrt pulls patches from newer versions, it did bring in patches from v6.2 which reverts this model, and again makes “.wake_tx_queue” a mandatory callback in Openwrt.

git.openwrt.org Git - openwrt/openwrt.git/blob - package/kernel/mac80211/patches/subsys/306-01-v6.2-wifi-mac80211-add-internal-handler-for-wake_tx_queue.patch

To mitigate this situation, we assign “ieee80211_handle_wake_tx_queue" as the wake_tx_queue callback in our wireless driver.

I also see that there was a regression in mac80211 which was fixed as a part of the following patch

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

This is cherry-picked into 6.1.24 Mac80211 as suitable for it, but Openwrt with its patches has brought back in the "wake_tx_push_queue" function but did not bring the changes from the above patch to fix the issue.

So if I bring that in as in the patch currently added everything is back to normal,

[Leo-PL]

I applied the patch to my tree and built fine on ath79. I'll be testing it for a short while, on wednesday I probably should have more detailed information.

[morse-sophronia]

@Leo-PL Thanks that'll be of great help

[sppmasterspp]

What is the difference with this PR #14929
except for the fact there is a second commit there.
Maybe it's for the main branch but the changed code is different.

[systemcrash]

What is the difference with this PR #14929 except for the fact there is a second commit there. Maybe it's for the main branch but the changed code is different.

The two seem unrelated, and the pfx stuff probably should not be here. 🤷

[Leo-PL]

Yeah, it simply looks pushed by mistake

[hauke]

Why don't you bring in the full patch from 6.1 stable? gregkh/linux@7b8fe53

[morse-sophronia]

@sppmasterspp @systemcrash @Leo-PL Yes the second commit was a mistake, that is unrelated to this issue, I have removed that commit

[morse-sophronia]

@hauke We don't need the full commit as it is partially brought in mac80211 v6.1.24 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/net/mac80211?h=v6.1.24&id=7b8fe53d2a1da48db02ae961b29b8ee2f5515861

[sppmasterspp]

@morse-sophronia
I test this patch package/kernel/mac80211/patches/subsys/306-wifi-mac80211-proper-mark-iTXQs-for-resumption.patch on R7800 with ath10k driver and firmware (non -ct variant) running 23.05 snapshot NSS build (kernel 5.15.150) along with @Ansuel https://github.com/openwrt/openwrt/pull/12904/commits.
What should we expect? Do you want us to report anything?
Should we look for anything more specific?

[Leo-PL]

I'm still waiting for more detailed feedback from folks at my local hackerspace. No explicit tests, but there seems to be an improvement. I can't really test that myself, because everything was working fine between Archer C7v2 and QCA6174 under Linux on my laptop - only some devices experienced troubles.