Felix Fietkau <nbd@xxxxxxxx> writes: > On 2020-02-26 22:56, Toke Høiland-Jørgensen wrote: >> Felix Fietkau <nbd@xxxxxxxx> writes: >>> - We need an API that allows the driver to change the pending airtime >>> values, e.g. subtract estimated tx time for a packet. >>> mt76 an ath9k can queue packets inside the driver that are not currently >>> in the hardware queues. Typically if the txqs have more data than what >>> gets put into the hardware queue, both drivers will pull an extra frame >>> and queue it in its private txq struct. This frame will get used on the >>> next txq scheduling round for that particular station. >>> If you have lots of stations doing traffic (or having driver buffered >>> frames in powersave mode), this could use up a sizable chunk of the AQL >>> budget. >> >> I'm a bit more skeptical about this. If the driver buffers a bunch of >> packets that are not accounted that will hurt that station due to extra >> latency when it wakes up. For ath9k, this is the retry_q you're talking >> about, right? The number of packets queued on that is fairly limited, >> isn't it? What kind of powersave buffering is the driver doing, and why >> can't it leave the packets on the TXQ? That would allow them to be >> scheduled along with any new ones that might have arrived in the >> meantime, which would be a benefit for latency. > For mt76 there should be max. 1 frame in the retry queue, it's just a > frame that was pulled from the txq in a transmission attempt but that it > couldn't put in the hw queue because it didn't fit in the current > aggregate batch. Wait, if it's only a single frame that is queued in the driver, how is this causing problems? We deliberately set the limit so there was a bit of slack above the size of an aggregate for things like this. Could you please describe in a bit more detail what symptoms you are seeing of this problem? :) -Toke
