Re: [PATCH] wifi: mac80211: keep the TXQ scheduling round number across a closed round

[Johannes Berg <johannes@sipsolutions.net>]

On Tue, 2026-09-08 at 15:52 +0200, Julius Bairaktaris wrote:
> ieee80211_txq_schedule_start() sets local->schedule_round[ac] to 0 when
> the access category is over its airtime limit, so that
> ieee80211_next_txq() serves nothing until a round passes the check
> again. That round is then numbered 1. ieee80211_next_txq() ends a round
> when it reaches a txq whose schedule_round equals the current number,
> so a txq served in a round numbered 1 is skipped in the next round
> numbered 1 as well.
> 
> Where the airtime queue limit binds, closed and open rounds alternate,
> so half of the rounds that could refill the queue return nothing.
> 
> Track whether a round is open in its own flag and leave the round
> number alone. Checking the limit in ieee80211_next_txq() instead would
> walk the active list once per txq served rather than once per round.
> 
> Measured on an IPQ8074 AP with ath11k advertising AQL through the
> series "wifi: ath11k: airtime queue limits, fairness and a driver TXQ
> scheduler", one 1x1 VHT80 station, BE aql_txq_limit 500/1000 us, 20 s
> runs, three interleaved runs per arm, the skipped selections counted
> where ieee80211_next_txq() ends the round. With a TCP download
> forwarded from a wired host, 4227, 4195 and 4268 selections are skipped
> per run without this change and 15, 24 and 41 with it, at 99 to 100
> Mbit/s either way: the network stack's arrivals start rounds often
> enough to cover the loss. With the download generated on the access
> point, where TCP small queues pace the arrivals, the skipped rounds are
> the ones that would have refilled the queue: 35.6, 44.4 and 42.8 Mbit/s
> without this change and 94.7, 94.6 and 95.0 with it.
> 

For the record - one last time - since you keep writing everything with
an LLM I will keep dropping it unread.

johannes