All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Felix Fietkau <nbd@nbd.name>, Kan Yan <kyan@google.com>,
	johannes@sipsolutions.net
Cc: linux-wireless@vger.kernel.org,
	make-wifi-fast@lists.bufferbloat.net, yiboz@codeaurora.org,
	john@phrozen.org, lorenzo@kernel.org, rmanohar@codeaurora.org,
	kevinhayes@google.com
Subject: Re: [PATCH v11 4/4] mac80211: Use Airtime-based Queue Limits (AQL) on packet dequeue
Date: Thu, 27 Feb 2020 11:07:29 +0100	[thread overview]
Message-ID: <875zfsxs0u.fsf@toke.dk> (raw)
In-Reply-To: <829b6b28-99cd-ea9d-fea3-603a10eae401@nbd.name>

Felix Fietkau <nbd@nbd.name> writes:

> On 2020-02-26 22:56, Toke Høiland-Jørgensen wrote:
>> Felix Fietkau <nbd@nbd.name> 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


  reply	other threads:[~2020-02-27 10:07 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-19  6:06 [PATCH v11 0/4] Add Airtime Queue Limits (AQL) to mac80211 Kan Yan
2019-11-19  6:06 ` [PATCH v11 1/4] mac80211: Add new sta_info getter by sta/vif addrs Kan Yan
2019-11-19  6:06 ` [PATCH v11 2/4] mac80211: Import airtime calculation code from mt76 Kan Yan
2019-11-22 12:12   ` Johannes Berg
2019-11-22 12:56     ` Toke Høiland-Jørgensen
2019-11-22 13:00       ` Johannes Berg
2019-11-22 13:11         ` Toke Høiland-Jørgensen
2019-11-22 13:15           ` Johannes Berg
2019-11-22 14:41             ` Toke Høiland-Jørgensen
2019-11-22 12:27   ` Johannes Berg
2019-11-22 12:56     ` Toke Høiland-Jørgensen
2019-11-19  6:06 ` [PATCH v11 3/4] mac80211: Implement Airtime-based Queue Limit (AQL) Kan Yan
2019-11-19  6:06 ` [PATCH v11 4/4] mac80211: Use Airtime-based Queue Limits (AQL) on packet dequeue Kan Yan
2020-02-26 20:30   ` Felix Fietkau
2020-02-26 21:56     ` Toke Høiland-Jørgensen
2020-02-27  8:24       ` Kan Yan
2020-02-27 10:42         ` Felix Fietkau
2020-02-27 11:07           ` Toke Høiland-Jørgensen
2020-02-27 12:00             ` Felix Fietkau
2020-02-27  8:34       ` Felix Fietkau
2020-02-27 10:07         ` Toke Høiland-Jørgensen [this message]
2020-02-27 11:34           ` Felix Fietkau
2020-02-27 11:59             ` Toke Høiland-Jørgensen
2020-02-27  9:25   ` Justin Capella
2020-02-27 10:17     ` Toke Høiland-Jørgensen

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=875zfsxs0u.fsf@toke.dk \
    --to=toke@redhat.com \
    --cc=johannes@sipsolutions.net \
    --cc=john@phrozen.org \
    --cc=kevinhayes@google.com \
    --cc=kyan@google.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=lorenzo@kernel.org \
    --cc=make-wifi-fast@lists.bufferbloat.net \
    --cc=nbd@nbd.name \
    --cc=rmanohar@codeaurora.org \
    --cc=yiboz@codeaurora.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.