Lets make wifi fast again!
 help / color / mirror / Atom feed
From: Felix Fietkau <nbd@nbd.name>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>,
	"Rajkumar Manoharan" <rmanohar@codeaurora.org>,
	linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
Cc: make-wifi-fast@lists.bufferbloat.net
Subject: Re: [Make-wifi-fast] [PATCH v3 3/6] mac80211: Add airtime accounting and scheduling to TXQs
Date: Thu, 15 Nov 2018 12:09:08 +0100	[thread overview]
Message-ID: <8e7847ff-4c88-10ae-2223-2fc7321641d9@nbd.name> (raw)
In-Reply-To: <871s7nv9pl.fsf@toke.dk>

On 2018-11-14 18:40, Toke Høiland-Jørgensen wrote:
>> This part doesn't really make much sense to me, but maybe I'm
>> misunderstanding how the code works.
>> Let's assume we have a driver like ath9k or mt76, which tries to keep a
>> number of aggregates in the hardware queue, and the hardware queue is
>> currently empty.
>> If the current txq entry is kept at the head of the schedule list,
>> wouldn't the code just pull from that one over and over again, until
>> enough packets are transmitted by the hardware and their tx status
>> processed?
>> It seems to me that while fairness is still preserved in the long run,
>> this could lead to rather bursty scheduling, which may not be
>> particularly latency friendly.
> 
> Yes, it'll be a bit more bursty when the hardware queue is completely
> empty. However, when a TX completion comes back, that will adjust the
> deficit of that sta and cause it to be rotated on the next dequeue. This
> obviously relies on the fact that the lower-level hardware queue is
> sufficiently shallow to not add a lot of latency. But we want that to be
> the case anyway. In practice, it works quite well for ath9k, but not so
> well for ath10k because it has a large buffer in firmware.
> 
> If we requeue the TXQ at the end of the list, a station that is taking
> up too much airtime will fail to be throttled properly, so the
> queue-at-head is kinda needed to ensure fairness...
Thanks for the explanation, that makes sense to me. I have an idea on
how to mitigate the burstiness within the driver. I'll write it down in
pseudocode, please let me know if you think that'll work.

do {
	struct ieee80211_txq *pending_txq[4];
	int n_pending_txq = 0;
	int i;

	if (hwq->pending < 4)
		break;

	nframes = 0;

	ieee80211_txq_schedule_start(hw, ac)
	do {
		bool requeue = false;

		struct ieee80211_txq *txq;

		txq = ieee80211_next_txq(hw, ac);
		if (!txq)
			break;

		nframes += schedule_txq(txq, &requeue);
		if (requeue)
			pending_txq[n_pending_txq++] = txq;

	} while (n_pending_txq < ARRAY_SIZE(pending_txq));

	for (i = n_pending_txq; i > 0; i--)
		ieee80211_return_txq(hw, pending_txq[i - 1]);

	ieee80211_txq_schedule_end(hw, ac)
} while (nframes);

- Felix

  reply	other threads:[~2018-11-15 11:09 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-12 22:51 [Make-wifi-fast] [PATCH v3 0/6] Move TXQ scheduling and airtime fairness into mac80211 Rajkumar Manoharan
2018-11-12 22:51 ` [Make-wifi-fast] [PATCH v3 1/6] mac80211: Add TXQ scheduling API Rajkumar Manoharan
2018-11-12 22:51 ` [Make-wifi-fast] [PATCH v3 2/6] cfg80211: Add airtime statistics and settings Rajkumar Manoharan
2018-11-12 22:51 ` [Make-wifi-fast] [PATCH v3 3/6] mac80211: Add airtime accounting and scheduling to TXQs Rajkumar Manoharan
2018-11-14 10:57   ` Felix Fietkau
2018-11-14 17:40     ` Toke Høiland-Jørgensen
2018-11-15 11:09       ` Felix Fietkau [this message]
2018-11-15 17:24         ` Toke Høiland-Jørgensen
2018-11-19 17:55           ` Dave Taht
2018-11-19 22:44             ` Toke Høiland-Jørgensen
2018-11-19 23:30               ` Dave Taht
2018-11-19 23:30               ` Simon Barber
2018-11-19 23:47                 ` Dave Taht
     [not found]                   ` <b0662c97-fb17-3f9d-693e-2fec92535076@candelatech.com>
2018-11-20  0:13                     ` Dave Taht
     [not found]                       ` <6beaeb84-b705-335b-93a7-36176495099b@candelatech.com>
2018-11-20  0:37                         ` Dave Taht
2018-11-20  2:12                           ` David Lang
2018-11-20  0:52                         ` Simon Barber
2018-11-20  1:04                           ` Dave Taht
2018-11-19 23:02         ` Toke Høiland-Jørgensen
2018-12-04 14:55     ` Toke Høiland-Jørgensen
2018-11-15  8:18   ` Louie Lu
2018-11-15 17:10     ` Toke Høiland-Jørgensen
2018-12-18 12:11       ` Johannes Berg
2018-12-18 14:08         ` Dave Taht
2018-12-18 19:19         ` Toke Høiland-Jørgensen
2018-11-12 22:51 ` [Make-wifi-fast] [PATCH v3 4/6] ath9k: Switch to mac80211 TXQ scheduling and airtime APIs Rajkumar Manoharan
2018-11-12 22:51 ` [Make-wifi-fast] [PATCH v3 5/6] ath10k: migrate to mac80211 txq scheduling Rajkumar Manoharan
2018-11-12 22:51 ` [Make-wifi-fast] [PATCH v3 6/6] ath10k: reporting estimated tx airtime for fairness Rajkumar Manoharan

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=8e7847ff-4c88-10ae-2223-2fc7321641d9@nbd.name \
    --to=nbd@nbd.name \
    --cc=ath10k@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=make-wifi-fast@lists.bufferbloat.net \
    --cc=rmanohar@codeaurora.org \
    --cc=toke@toke.dk \
    /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