All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Yibo Zhao <yiboz@codeaurora.org>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	linux-wireless@vger.kernel.org,
	make-wifi-fast@lists.bufferbloat.net,
	John Crispin <john@phrozen.org>,
	Lorenzo Bianconi <lorenzo@kernel.org>,
	Felix Fietkau <nbd@nbd.name>,
	linux-wireless-owner@vger.kernel.org
Subject: Re: [PATCH RFC/RFT 4/4] mac80211: Apply Airtime-based Queue Limit (AQL) on packet dequeue
Date: Wed, 25 Sep 2019 10:11:08 +0200	[thread overview]
Message-ID: <87y2yc3ieb.fsf@toke.dk> (raw)
In-Reply-To: <2f6b649dcb788222e070ebb5593918c7@codeaurora.org>

Yibo Zhao <yiboz@codeaurora.org> writes:

> So if it is going to work together with virtual time based mechanism in 
> the future, the Tx criteria will be met both of below conditions,
>         1. Lower than g_vt
>         2. Lower than IEEE80211_AIRTIME_QUEUE_LIMIT

> Are we going to maintain two kinds of airtime that one is from 
> estimation and the other is basically from FW reporting?

Yes, that was my plan. For devices that don't have FW reporting of
airtime, we can fall back to the estimation; but if we do have FW
reporting that is most likely going to be more accurate, so better to
use that for fairness...

> Meanwhile, airtime_queued will also limit the situation that we only
> have a station for transmission. Not sure if the peak throughput will
> be impacted. I believe it may work fine with 11ac in chromiumos, how
> about 11n and 11a?

Well, we will need to test that, of course. But ath9k shows that it's
quite possible to run with quite shallow buffers, so with a bit of
tuning I think we should be fine. If anything, slower networks need
*fewer* packets queued in the firmware, and it's *easier* for the host
to keep up with transmission.

> Anyway, I think this approach will help to improve performance of the 
> virtual time based mechanism since it makes packets buffered in host 
> instead of FW's deep queue. We have observed 2-clients case with 
> different ratio in TCP fails to maintain the ratio because the packets 
> arriving at host get pushed to FW immediately and thus the airtime 
> weight sum is 0 in most of time meaning no TXQ in the rbtree. For UDP, 
> if we pump load more than the PHY rate, the ratio can be maintained 
> beacuse the FW queue is full and packtes begin to be buffered in host 
> making TXQs staying on the rbtree for most of time. However, TCP has its 
> own flow control that we can not push enough load like UDP.

Yes, fixing that is exactly the point of this series :)

-Toke


  reply	other threads:[~2019-09-25  8:11 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-19 12:22 [PATCH RFC/RFT 0/4] Add Airtime Queue Limits (AQL) to mac80211 Toke Høiland-Jørgensen
2019-09-19 12:22 ` [PATCH RFC/RFT 1/4] mac80211: Rearrange ieee80211_tx_info to make room for tx_time_est Toke Høiland-Jørgensen
2019-10-01  8:44   ` Johannes Berg
2019-10-01  9:08     ` Toke Høiland-Jørgensen
2019-10-01  9:12       ` Johannes Berg
2019-10-01  9:39         ` Toke Høiland-Jørgensen
2019-09-19 12:22 ` [PATCH RFC/RFT 2/4] mac80211: Add API function to set the last TX bitrate for a station Toke Høiland-Jørgensen
2019-10-01  8:46   ` Johannes Berg
2019-10-01  9:09     ` Toke Høiland-Jørgensen
2019-09-19 12:22 ` [PATCH RFC/RFT 3/4] ath10k: Pass last TX bitrate up to mac80211 Toke Høiland-Jørgensen
2019-09-19 12:22 ` [PATCH RFC/RFT 4/4] mac80211: Apply Airtime-based Queue Limit (AQL) on packet dequeue Toke Høiland-Jørgensen
2019-09-19 17:44   ` Peter Oh
2019-09-19 17:46     ` Ben Greear
2019-09-19 17:54       ` Peter Oh
2019-09-19 18:03         ` Peter Oh
2019-09-19 18:18           ` [Make-wifi-fast] " Dave Taht
2019-09-19 20:09             ` John Yates
2019-09-19 20:15               ` Toke Høiland-Jørgensen
2019-09-19 18:03         ` Toke Høiland-Jørgensen
2019-09-20 12:06   ` Lorenzo Bianconi
2019-09-20 12:54     ` Toke Høiland-Jørgensen
2019-09-20 13:06       ` Lorenzo Bianconi
2019-09-20 13:32         ` Toke Høiland-Jørgensen
2019-09-20 22:55           ` Kan Yan
2019-09-21 12:11             ` Toke Høiland-Jørgensen
2019-09-25  7:37   ` Yibo Zhao
2019-09-25  8:11     ` Toke Høiland-Jørgensen [this message]
2019-09-25 11:54       ` Yibo Zhao
2019-09-25 12:52         ` Toke Høiland-Jørgensen
2019-09-26  0:27           ` Kan Yan
2019-09-26  0:34             ` Kan Yan
2019-09-26  5:57               ` Toke Høiland-Jørgensen
2019-09-26  6:04             ` Toke Høiland-Jørgensen
2019-09-26 12:53   ` Felix Fietkau
2019-09-26 13:17     ` Toke Høiland-Jørgensen
2019-09-26 13:47       ` Felix Fietkau
2019-09-26 15:19         ` Toke Høiland-Jørgensen
2019-09-27  2:42           ` Kan Yan
2019-09-27  6:12             ` Toke Høiland-Jørgensen
2019-09-27  9:20               ` Yibo Zhao
2019-09-28 20:24                 ` Kan Yan
2019-09-29 19:18                   ` Toke Høiland-Jørgensen
2019-10-01  4:47                     ` Kan Yan
2019-10-01  6:57                       ` Toke Høiland-Jørgensen
2019-09-19 14:12 ` [PATCH RFC/RFT 0/4] Add Airtime Queue Limits (AQL) to mac80211 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=87y2yc3ieb.fsf@toke.dk \
    --to=toke@redhat.com \
    --cc=johannes@sipsolutions.net \
    --cc=john@phrozen.org \
    --cc=linux-wireless-owner@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=lorenzo@kernel.org \
    --cc=make-wifi-fast@lists.bufferbloat.net \
    --cc=nbd@nbd.name \
    --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.