Hi Alexander,
On 2/17/25 12:17 AM, Alexander Wetzel wrote:
This series switches all TX handling in mac80211 over to TXQs.
TXQs can take over buffering in many - potentially even all - cases
where we use separate solutions so far.
This reduces the complexity of the TX path and making it simpler to use
TX in mac8021.
These patches continue the work to get rid of the legacy TX path we
started drivers with
https://lore.kernel.org/r/20221009163040.25637-1-alexander@xxxxxxxxxxxxxx
and was inspired by this old discussion on the wireless mailing list:
https://lore.kernel.org/r/1507217947.2387.60.camel@xxxxxxxxxxxxxxxx/
Changes compared to RFC and v1 are documented in the individual patches,
where applicable.
A quick overview of the patches in the series:
wifi: mac80211: move rate control setup
Broken off from "Add new TX queues to replace legacy TX" as
requested. Moves some exiting code around.
wifi: mac80211: Always provide the MMPDU TXQ
When only using TXQs for TX we akways need this.
Creates and uses MMPDU TXQs even for drivers not supporting
them.
wifi: mac80211: Convert vif->txq to an array
We need some more TXQs for the patch below. Create them.
wifi: mac80211: Add new TX queues to replace legacy TX
This starts the core of the move to TXQs.
Creats all the missing TXQs and updates the support function for
them. It also directly switches traffic to them, when possible.
(Only offchannel is sticking to legacy TX after that.)
wifi: mac80211: Stop using legacy TX path
Drop the legacy TX functions and move offchannel TX to the new
alternate TXQ path named TXQ_NOQUEUE (so far).
With that mac80211 has two TX paths both using TXQ:
- The existing one, which uses the TXQ for queuing and
- TXQ_NOQUEUE. Which just puts frames into a TXQ and
immediately sends out the frame by also calling drv_tx() for
it. There never can be more than one frame in any of these
TXQs. They never see a wake_tx_queue call by the driver or
mac80211.
wifi: mac80211: Call ieee80211_tx_h_select_key only once
A optimization which could be without the patches, too. Would
just be done differently. (Not required)
wifi: mac80211: Rename IEEE80211_TX_INTFL_OFFCHAN_TX_OK
Rename the flag used to select the NOQUEU TX path to make its
use more obvious.
wifi: mac80211: Simplify AMPDU handling
Uses TXQs to buffer frames when AMPDU is started/stopped.
wifi: mac80211: Migrate TX to kthread
Moves all TX operation except TXQ_NOQUEUE to a new kthread.
This hooks into the existing txq scheduling and uses
local->active_txqs to determine which TXQs need to run.
wifi: mac80211: Cleanup *ieee80211_wake_txq* naming
Rename a few functions.
drivers/net/wireless/ath/ath10k/mac.c | 8 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 2 +-
.../net/wireless/intel/iwlwifi/mvm/mac80211.c | 6 +-
.../net/wireless/mediatek/mt76/mt7603/main.c | 3 +-
.../net/wireless/mediatek/mt76/mt7615/main.c | 5 +-
.../net/wireless/mediatek/mt76/mt76x02_util.c | 3 +-
.../net/wireless/mediatek/mt76/mt7915/main.c | 6 +-
.../net/wireless/mediatek/mt76/mt7921/main.c | 5 +-
.../net/wireless/mediatek/mt76/mt7925/main.c | 5 +-
.../net/wireless/mediatek/mt76/mt7996/main.c | 5 +-
drivers/net/wireless/realtek/rtw88/mac80211.c | 4 +-
drivers/net/wireless/realtek/rtw88/main.c | 2 +-
drivers/net/wireless/realtek/rtw89/mac80211.c | 2 +-
include/net/mac80211.h | 60 +-
net/mac80211/agg-tx.c | 129 +---
net/mac80211/cfg.c | 8 +-
net/mac80211/debugfs_netdev.c | 46 +-
net/mac80211/debugfs_sta.c | 2 -
net/mac80211/driver-ops.h | 28 +-
net/mac80211/ieee80211_i.h | 32 +-
net/mac80211/iface.c | 144 ++--
net/mac80211/main.c | 9 +-
net/mac80211/mesh.c | 13 +-
net/mac80211/mlme.c | 2 +-
net/mac80211/offchannel.c | 2 +-
net/mac80211/rx.c | 11 +-
net/mac80211/scan.c | 2 +-
net/mac80211/sta_info.c | 6 +-
net/mac80211/sta_info.h | 30 +-
net/mac80211/tx.c | 616 ++++--------------
net/mac80211/util.c | 162 +++--
31 files changed, 534 insertions(+), 824 deletions(-)
Trying to get some clarity if this might fix a regression [1] with
ath10k where upon roaming the TX queue hangs on flush for ~4-10 seconds.
I was hopeful for another set [2] but it looks like this only effected
AP mode and with that applied I still notice the behavior.
In the worse case we see two failures, which add up to about 10 seconds
of delays, more often its just the single "failed to flush transmit queue"
Feb 19 14:15:59 kernel: ath10k_pci 0000:02:00.0: failed to flush sta txq
(sta 6a:3a:0e:22:45:08 skip 0 ar-state 1): 0
Feb 19 14:16:04 kernel: ath10k_pci 0000:02:00.0: failed to flush
transmit queue (skip 0 ar-state 1): 0
Crossing my fingers this set will have some positive effect here
[1]
https://lore.kernel.org/all/CA+Xfe4FjUmzM5mvPxGbpJsF3SvSdE5_wgxvgFJ0bsdrKODVXCQ@xxxxxxxxxxxxxx/
[2]
https://lore.kernel.org/linux-wireless/cover.1732293922.git.repk@xxxxxxxxxxxx/
Thanks,
James
