All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Julius Bairaktaris <julius@bairaktaris.de>,
	Jeff Johnson <jjohnson@kernel.org>
Cc: linux-wireless@vger.kernel.org, ath11k@lists.infradead.org
Subject: Re: [PATCH v1 4/4] wifi: ath11k: report tx airtime and enable airtime fairness
Date: Mon, 24 Aug 2026 12:53:33 +0200	[thread overview]
Message-ID: <87se43eqmq.fsf@toke.dk> (raw)
In-Reply-To: <20260823195703.49198-5-julius@bairaktaris.de>

Julius Bairaktaris <julius@bairaktaris.de> writes:

> mac80211's airtime scheduler charges sta->airtime[ac].deficit from one
> place, ieee80211_sta_register_airtime(). Unlike AQL there is no estimator
> fallback, and ath11k never calls it, so the ATF feature bit cannot be
> advertised on its own: the deficit would only ever be
> replenished, every station would stay permanently in credit, and the DRR
> would be inert. The bit is not a no-op in that state either, because it
> also moves txq insertion to the head of the active list, which
> __ieee80211_schedule_txq() documents as safe only because the DRR moves a
> station back once its deficit goes negative.
>
> fes_duration_us arrives with every PPDU's stats and is already
> accumulated into arsta->tx_duration a few lines above. Register it, and
> set the feature bit in the same change so the two cannot be separated.
>
> Measured on an IPQ8074 AP with two stations on one radio, a 1x1 VHT
> client at 433 Mbit/s and a 2x2 HE client, both receiving at once. Before,
> 'iw station set <mac> airtime_weight' is refused with -EOPNOTSUPP and the
> per-station airtime file reads zero. After, the weight is accepted and
> read back, TX airtime accumulates, and the per-AC deficits move.
>
> The fairness this delivers is coarse. Weighting the fast station 4:1 moves
> the slow station's share of airtime from 59.5% to 52.1% and the fast
> station's throughput from 315 to 392 Mbit/s: the direction is correct, the
> magnitude is not the ratio requested.

How consistent is this change between runs? Seems a bit marginal if the
policy was supposed to give a 4:1 ratio between stations, so does this
work at all?

-Toke

      reply	other threads:[~2026-08-24 10:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-23 19:56 [PATCH v1 0/4] wifi: ath11k: enable airtime queue limits and fairness Julius Bairaktaris
2026-08-23 19:57 ` [PATCH v1 1/4] wifi: ath11k: free tx skbs through ieee80211_free_txskb() Julius Bairaktaris
2026-08-23 19:57 ` [PATCH v1 2/4] wifi: ath11k: enable airtime queue limits Julius Bairaktaris
2026-08-24 10:46   ` Toke Høiland-Jørgensen
2026-08-23 19:57 ` [PATCH v1 3/4] wifi: ath11k: report the pending tx MSDU count in soc_dp_stats Julius Bairaktaris
2026-08-23 19:57 ` [PATCH v1 4/4] wifi: ath11k: report tx airtime and enable airtime fairness Julius Bairaktaris
2026-08-24 10:53   ` Toke Høiland-Jørgensen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87se43eqmq.fsf@toke.dk \
    --to=toke@toke.dk \
    --cc=ath11k@lists.infradead.org \
    --cc=jjohnson@kernel.org \
    --cc=julius@bairaktaris.de \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.