(This discussion will mainly circle on
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
- Dead, the Marvell Wireless business unit doesn't exist anymore (bought by NXP)
- There are barely any comments in the code
- A lot of stuff is locked behind the firmware
The code base is very similar to
I know that the following is needed for ATF support:
and I'll need to add the following attributes:
mwlwifi do not use
ieee80211_txq. However, at least
mwl8k has a starting point in
I'm thinking I'll need to look more closely at one/some of these:
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
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.
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
Have not compile-tested it yet.
EDIT: Missed a patch – https://pastebin.com/2EJnYznv
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
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]:
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:
It contains things like:
If we can somehow adopt the above to use ieee80211_txq, then the ATF and AQL features can follow.
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.
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.
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
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.