[Battlemesh] per station queueing hook in mac80211
dave.taht at gmail.com
Fri Aug 7 15:47:15 CEST 2015
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
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
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.
Author: Felix Fietkau <nbd at openwrt.org>
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 <chromatix99 at gmail.com> wrote:
>> On 7 Aug, 2015, at 15:22, Rich Brown <richb.hanover at gmail.com> 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
> Make-wifi-fast at lists.bufferbloat.net
worldwide bufferbloat report:
What will it take to vastly improve wifi for everyone?
More information about the Battlemesh