| Message ID | 20250217081721.45110-1-Alexander@wetzel-home.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | Convert mac80211 to TXQs only | expand |
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@wetzel-home.de > > and was inspired by this old discussion on the wireless mailing list: > https://lore.kernel.org/r/1507217947.2387.60.camel@sipsolutions.net/ > > 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@mail.gmail.com/ [2] https://lore.kernel.org/linux-wireless/cover.1732293922.git.repk@triplefau.lt/ Thanks, James
On 19.02.25 20:19, James Prestwood wrote: ... >> > 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 > I had a quick look at ath10k driver and the error message you have. The patch series here will probably not help with that. From driver perspective nothing relevant should be different... > [1] https://lore.kernel.org/all/ > CA+Xfe4FjUmzM5mvPxGbpJsF3SvSdE5_wgxvgFJ0bsdrKODVXCQ@mail.gmail.com/ > [2] https://lore.kernel.org/linux-wireless/ > cover.1732293922.git.repk@triplefau.lt/ > > Thanks, > > James >
Hi, On 2/19/25 1:27 PM, Alexander Wetzel wrote: > On 19.02.25 20:19, James Prestwood wrote: > ... >>> >> 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 >> > > I had a quick look at ath10k driver and the error message you have. > The patch series here will probably not help with that. From driver > perspective nothing relevant should be different... Well thank you for looking at least, I appreciate that. > > >> [1] https://lore.kernel.org/all/ >> CA+Xfe4FjUmzM5mvPxGbpJsF3SvSdE5_wgxvgFJ0bsdrKODVXCQ@mail.gmail.com/ >> [2] https://lore.kernel.org/linux-wireless/ >> cover.1732293922.git.repk@triplefau.lt/ >> >> Thanks, >> >> James >> >
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@wetzel-home.de and was inspired by this old discussion on the wireless mailing list: https://lore.kernel.org/r/1507217947.2387.60.camel@sipsolutions.net/ 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(-)