Porting airtime fairness (+ airtime queue limits?)

(This discussion will mainly circle on mwlwifi)

It's a sad state to see that some ath9k devices have more active development and longevity than some 802.11ac chips.

I want to attempt porting airtime fairness to my device that uses mwlwifi but I think I've already run into some roadblocks.

I know that mwlwifi is:

  1. Out-of-tree
  2. Dead, the Marvell Wireless business unit doesn't exist anymore (bought by NXP)
  3. There are barely any comments in the code
  4. A lot of stuff is locked behind the firmware

The code base is very similar to mwl8k.

I know that the following is needed for ATF support:

  • ieee80211_next_txq()
  • ieee80211_return_txq()
  • ieee80211_txq_schedule_start
  • ieee80211_txq_schedule_end

and I'll need to add the following attributes:

  • NL80211_STA_INFO_TX_DURATION
  • NL80211_STA_INFO_AIRTIME_WEIGHT
  • NL80211_EXT_FEATURE_AIRTIME_FAIRNESS

But both mwl8k and mwlwifi do not use ieee80211_txq. However, at least mwl8k has a starting point in mwl8k_txq_init.

I'm thinking I'll need to look more closely at one/some of these:

  • pcie_tx_init
  • pcie_tx_deinit
  • pcie_tx_skbs

Or some other stuff here: https://github.com/kaloz/mwlwifi/blob/master/hif/pcie/tx.c

I'd really like to know if there is something worth pursuing in this, or should I just give up...

The last time the code was reviewed by Linux wireless was: https://patchwork.kernel.org/patch/9482477/

Tagging the more knowledgeable people with Linksys WRT AC series hardware in this discussion (and have had longer ownership of this devices in this series than me):
@eduperez @mindwolf @solidus1983 @davidc502

1 Like

This does not directly answer your question, but the MT76 driver has AC and airtime fairness support. Might be an easier solution to switch to a MT76 device instead of trying to port the functionality. Especially since a much larger part of the driver is closed source for mlwifi in the form of firmware blobs. Thankfully the MT76 uses very small firmware blobs (although I would have preferred full opensource drivers of course)

Would it be best to see what the blobs control first seems only logical to be honest.

There is an active effort to mainline AQL at the mac80211 layer (see e.g. [PATCH v11 0/4] Add Airtime Queue Limits (AQL) to mac80211).

I don't know how this impacts mwlwifi/mwl8k and if this will add support for AQL in mwlwifi/mwl8k, but IIRC this mac80211 approach seeks to eliminate the need to add AQL from scratch in every single driver.

1 Like

It has already been pulled in by Linus for 5.5

It looks to be much easier to port over into mwl8k/mwlwifi.

Backported the patch for OpenWrt Master-5f68333952 here. Copy as 700-Add-Airtime-Queue-Limits-Master-5f68333952.patch into {working_dir}/package/kernel/mac80211/subsys/

Have not compile-tested it yet.

EDIT: Missed a patch – https://pastebin.com/2EJnYznv

1 Like

Having just read through the code in a much more thorough manner, I don't think it will do anything differently for the Marvell Wireless chipsets. It still needs struct ieee80211_txq(). Neither mwlwifi nor mwl8k expose their txqs to mac80211. Thus, it won't benefit from this change.

Who will benefit? Current of users of ieee80211_txq() are [in Linux 5.4]:

  • ath10k
  • ath9k
  • iwlwifi
  • mt76

EDIT: I'm closing this since I've answered my own question – no it's not possible (at least with my level of C knowledge and driver coding) to port ATF and AQL for mwlwifi because it's queues aren't managed by mac80211. It will require drastic changes and a sizeable amount of time to refactor mwlwifi to use that.

I also had it wrong – one also needs to look into:
mwlwifi's mac80211.c file.
It contains things like:

  • mwl_get_rateinfo
  • mwl_mac80211_tx
  • mwl_mac80211_conf_tx
  • mwl_mac80211_get_stats
  • mwl_mac80211_ampdu_action

If we can somehow adopt the above to use ieee80211_txq, then the ATF and AQL features can follow.

EDIT 2:
Kindly pinging @dtaht and @tohojo for a second opinion on https://github.com/kaloz/mwlwifi/ (https://patchwork.kernel.org/patch/9482477/)

Thank you for taking the time in your busy days for this if you do read this.

4 Likes

Will also check this out as well.

Edit: Just about to compile it now.

Edit 2: On a known good build it failed to recompile with that patch included however its compiled fine since after removing the patch.

You're basically right that mwlwifi would need to be ported over to use the mac80211 TXQ path to make use of AQL and airtime fairness.

1 Like

And just a general note on terminology, since this can be confusing: What mac80211 calls a "TXQ" is an abstract queueing structure controlled by FQ-CoDel where packets are kept until they are ready to transmit. Sorta like a qdisc on the netdev, but adapted to WiFi usage.

Whereas the queues drivers manage are hardware queues, i.e., the pipelines of packets that the hardware/firmware manages. Some drivers (e.g., ath9k) use the name "txq" for these hardware queues as well, while others (e.g., mt76 I think), call them "hwq". So there is not necessarily a one-to-one relationship between a "mac80211 TXQ", and a "hardware queue". Although, to confuse matters further, I think that the iwl driver does actually couple mac80211 TXQs to hardware queues.

This is just to say that it's not just "porting a driver to use mac80211 txqs"; it's a different API between mac80211 and the driver entirely. Contrast figures 1 and 3 in this: https://www.usenix.org/conference/atc17/technical-sessions/presentation/hoilan-jorgesen

To get an idea about what it takes to port a driver, this is the patch that converted ath9k: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=50f08edf98096a68f01ff4566b605a25bf8e42ce

2 Likes

I'd help port the driver but I have no idea how.
I've been trying to get some info from people related to this driver and either they don't answer or they don't know anything...

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.