[RFC,00/13] Convert mac80211 to TXQs only

This converts mac80211 to only use TXQs internally, moves TX into
a kthread and picks up some easy optimizations on the way.

The patches should all have merge-quality and are working both with
iwlmvm (as station) and with the hostapd tests without any known issues.
(Short of not yet including the PS and filtered frame migration to TXQs.)

The first three patches are mostly unrelated for the TXQ move.
When these are ok for you I could submit them independently, cutting
them off here.

Here a short overview of the patches in the series:
  wifi: mac80211: Fix virtual monitor interface creation
	This basically covers questions I have about the monitor handling,
	just posed as a patch. (It has it's own comment section).

  wifi: mac80211: Fix debugfs handling for virtual monitor
	Found during QA testing of this series. Otherwise unrelated.
	
  wifi: mac80211: Cleanup sta TXQs on flush
	Another thing I found during QA while working on an unrelated
	regression I caused.

  wifi: mac80211: Always provide the MMPDU TXQ
	When only using TXQs for TX we can't have this queue optionally.
	We probably want to discuss how to make that mandatory for all
	drivers with native TXQ support. But this works, allowing to
	soften the probably desired updates to (some) TXQ drivers.

  wifi: mac80211: Convert vif->txq to an array
	We need some more TXQs for the patch below. STA TXQs are already
	in an array, so just put the VIF TXQ into one, too.

  wifi: mac80211: Add new TX queues to replace legacy TX
	This here starts the "core" of the patch series.
	It's creating 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 here.)

  wifi: mac80211: Stop using legacy TX path
	This is dropping the legacy TX support and moves offchannel TX to
	the new alternate TXQ path: So far named TXQ_NOQUEUE.
	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
	This is just a simple drive-by optimization. Not needed.

  wifi: mac80211: Rename IEEE80211_TX_INTFL_OFFCHAN_TX_OK
	Also functionality irrelevant. Just seems to be a good way to use
	that as the official selector for the TXQ_NOQUEUE path and
	represent that in the name.

  wifi: mac80211: Simplify AMPDU handling
	Also a kind of drive-by optimization. Uses TXQs to buffer frames
	when AMPDU is started/stopped and even gets rid
	IEEE80211_QUEUE_STOP_REASON_AGGREGATION.

  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. We may also consider 
	forcing all drivers to use ieee80211_txq_schedule_start() to get
	rid of the code figuring that out per run...

  wifi: mac80211: Drop wake_txqs_tasklet
	Another drive-by cleanup/optimization which became possible due
	to the kthread patch above.

  wifi: mac80211: Cleanup *ieee80211_wake_txq* naming
	And finally a patch just renaming a few functions. Not sure if
	that avoids or adds confusion... 

As an outline:
When there are no fundamental concerns of the mayor changes in this
series I would try again to pick apart the PS buffering and filtered
frame mess. Which probably will have to be in one patch. Last time I tried
that without kthread it was not possible to rip it out independently.

On 1/27/2025 8:26 AM, Alexander Wetzel wrote:
> This converts mac80211 to only use TXQs internally, moves TX into
> a kthread and picks up some easy optimizations on the way.

It would be awesome if the cover letter actually described why these changes
are being proposed...