On 2019-09-19 14:22, Toke Høiland-Jørgensen wrote: > From: Toke Høiland-Jørgensen <toke@xxxxxxxxxx> > > Some devices have deep buffers in firmware and/or hardware which prevents > the FQ structure in mac80211 from effectively limiting bufferbloat on the > link. For Ethernet devices we have BQL to limit the lower-level queues, but > this cannot be applied to mac80211 because transmit rates can vary wildly > between packets depending on which station we are transmitting it to. > > To overcome this, we can use airtime-based queue limiting (AQL), where we > estimate the transmission time for each packet before dequeueing it, and > use that to limit the amount of data in-flight to the hardware. This idea > was originally implemented as part of the out-of-tree airtime fairness > patch to ath10k[0] in chromiumos. > > This patch ports that idea over to mac80211. The basic idea is simple > enough: Whenever we dequeue a packet from the TXQs and send it to the > driver, we estimate its airtime usage, based on the last recorded TX rate > of the station that packet is destined for. We keep a running per-AC total > of airtime queued for the whole device, and when that total climbs above 8 > ms' worth of data (corresponding to two maximum-sized aggregates), we > simply throttle the queues until it drops down again. > > The estimated airtime for each skb is stored in the tx_info, so we can > subtract the same amount from the running total when the skb is freed or > recycled. The throttling mechanism relies on this accounting to be > accurate (i.e., that we are not freeing skbs without subtracting any > airtime they were accounted for), so we put the subtraction into > ieee80211_report_used_skb(). > > This patch does *not* include any mechanism to wake a throttled TXQ again, > on the assumption that this will happen anyway as a side effect of whatever > freed the skb (most commonly a TX completion). > > The throttling mechanism only kicks in if the queued airtime total goes > above the limit. Since mac80211 calculates the time based on the reported > last_tx_time from the driver, the whole throttling mechanism only kicks in > for drivers that actually report this value. With the exception of > multicast, where we always calculate an estimated tx time on the assumption > that multicast is transmitted at the lowest (6 Mbps) rate. > > The throttling added in this patch is in addition to any throttling already > performed by the airtime fairness mechanism, and in principle the two > mechanisms are orthogonal (and currently also uses two different sources of > airtime). In the future, we could amend this, using the airtime estimates > calculated by this mechanism as a fallback input to the airtime fairness > scheduler, to enable airtime fairness even on drivers that don't have a > hardware source of airtime usage for each station. > > [0] https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/588190/13/drivers/net/wireless-4.2/ath/ath10k/mac.c#3845 One thing that might be missing here is dealing with airtime accounting of frames that remain queued in the driver/hardware because the station is in powersave mode. - Felix
