Lets make wifi fast again!
 help / color / mirror / Atom feed
From: Felix Fietkau <nbd@nbd.name>
To: "Toke Høiland-Jørgensen" <toke@redhat.com>, "Kan Yan" <kyan@google.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>,
	Yibo Zhao <yiboz@codeaurora.org>, John Crispin <john@phrozen.org>,
	Lorenzo Bianconi <lorenzo@kernel.org>,
	Rajkumar Manoharan <rmanohar@codeaurora.org>,
	Kevin Hayes <kevinhayes@google.com>
Subject: Re: [Make-wifi-fast] [PATCH v11 4/4] mac80211: Use Airtime-based Queue Limits (AQL) on packet dequeue
Date: Thu, 27 Feb 2020 13:00:27 +0100	[thread overview]
Message-ID: <c1a8b4a9-3cc7-fe23-b9f9-2a28d5ec2158@nbd.name> (raw)
In-Reply-To: <87o8tkwanq.fsf@toke.dk>

On 2020-02-27 12:07, Toke Høiland-Jørgensen wrote:
> Felix Fietkau <nbd@nbd.name> 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 :)
Makes sense, thanks.

- Felix

  reply	other threads:[~2020-02-27 12:00 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-19  6:06 [Make-wifi-fast] [PATCH v11 0/4] Add Airtime Queue Limits (AQL) to mac80211 Kan Yan
2019-11-19  6:06 ` [Make-wifi-fast] [PATCH v11 1/4] mac80211: Add new sta_info getter by sta/vif addrs Kan Yan
2019-11-19  6:06 ` [Make-wifi-fast] [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 ` [Make-wifi-fast] [PATCH v11 3/4] mac80211: Implement Airtime-based Queue Limit (AQL) Kan Yan
2019-11-19  6:06 ` [Make-wifi-fast] [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         ` [Make-wifi-fast] " Felix Fietkau
2020-02-27 11:07           ` Toke Høiland-Jørgensen
2020-02-27 12:00             ` Felix Fietkau [this message]
2020-02-27  8:34       ` Felix Fietkau
2020-02-27 10:07         ` Toke Høiland-Jørgensen
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

  List information: https://lists.bufferbloat.net/postorius/lists/make-wifi-fast.lists.bufferbloat.net/

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

  git send-email \
    --in-reply-to=c1a8b4a9-3cc7-fe23-b9f9-2a28d5ec2158@nbd.name \
    --to=nbd@nbd.name \
    --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=rmanohar@codeaurora.org \
    --cc=toke@redhat.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox