Felix Fietkau <nbd@xxxxxxxx> writes: >> Not sure I fully understand your concerns here. The AQL budget is per >> STA, per TID, so frames queued in the driver's special queue for one >> station won't impact another station's budget. Those frames are >> counted towards the per interface pending airtime, which could trigger >> AQL to switch to use the lower queue limit. In this case, that could >> be the desirable behavior when there is heavy traffic. > Yes, the per interface limit is what I'm concerned about. I'm not sure > if it will be an issue in practice, it's just something that I noticed > while reviewing the code. Ah, right. Note that it's not a hard limit, though; it's just a threshold for when the per-station limit switches to a smaller value. The idea is that when there are many stations with outstanding data, each station's latency will be higher since they have to also wait for their turn to transmit. And so we compensate for this by lowering each station's queue limit, since the hardware is unlikely to become idle when there are many stations to send to. The lower limit is still 5ms of data, though, so there should still be enough for a full aggregate queued for each station. Arguably the limit could actually be made *smaller*: On a very busy network with lots of stations transmitting at once, IMO we *don't* want to send full-sized aggregates as that will add up to way too much latency. Better to sacrifice a bit of network efficiency to raise responsiveness :) -Toke
