The core hook for doing per station queuing entered the linux kernel mainline back in march, by felix feitkau. (see below)
Due to the vast number of things that exist at the softmac layer (minstrel stats, retries, interference, and other data) needed to appropriately aggregate and schedule stuff, and vast differences in resources available from other wifi chipsets - this new hook is basically a per driver subsystem (which we think will at least work with ath9k, ath5k, and mt76), which we hope can one day evolve into a library of methods that can be called at the driver, rather than qdisc layer, to do better scheduling, aggregation, fq, and codel-ling in wifi. Operating at such a low level is hairy and full of locks, but all we need to do, at first, is a proof of concept that gets a start at the needed lib and mods... to rip out 100s or 1000s of ms from the current fixed sized single fifo buffering in the driver to something WAY smarter and less latent, that will take vastly better advantage of the 802.11n mac. and I have been meaning to buckle down (and get others to buckle down here!) and get our fingers dirty here for months. The potential benefits are enormous - all the base latency in the existing drivers goes away, at all bandwidths. commit ba8c3d6f16a1f9305c23ac1d2fd3992508c5ac03 Author: Felix Fietkau <[email protected]> Date: Fri Mar 27 21:30:37 2015 +0100 mac80211: add an intermediate software queue implementation This allows drivers to request per-vif and per-sta-tid queues from which they can pull frames. This makes it easier to keep the hardware queues short, and to improve fairness between clients and vifs. The task of scheduling packet transmission is left up to the driver - queueing is controlled by mac80211. Drivers can only dequeue packets by calling ieee80211_tx_dequeue. This makes it possible to add active queue management later without changing drivers using this code. This can also be used as a starting point to implement A-MSDU aggregation in a way that does not add artificially induced latency. On Fri, Aug 7, 2015 at 3:28 PM, Jonathan Morton <[email protected]> wrote: > >> On 7 Aug, 2015, at 15:22, Rich Brown <[email protected]> wrote: >> >> - At that time, the wifi driver requests packets from fq_codel until a) the >> the fq_codel queues are empty, or b) the wifi frame is full. In either case, >> the wifi driver sends what it has. > > There’s one big flaw with this: if packets are available for multiple > destinations, fq_codel will generally give you a variety pack of packets for > each of them. But a wifi TXOP is for a single destination, so only some of > the packets would be eligible for the same aggregate frame. > > So what’s needed is a way for the wifi driver to tell the queue that it wants > packets for the *same* destination as it’s transmitting to. > >> - Once the transmit opportunity has come around, it's a matter of >> microseconds (I assume) to pull in a wifi frame's worth of packets from >> fq_codel > > This is hard to guarantee in software in a general-purpose OS. > > - Jonathan Morton > > _______________________________________________ > Make-wifi-fast mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/make-wifi-fast -- Dave Täht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
