From: Felix Fietkau <nbd@nbd.name>
To: Alexander Wetzel <alexander@wetzel-home.de>,
Linux regressions mailing list <regressions@lists.linux.dev>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Thomas Mann <rauchwolke@gmx.net>,
Stanislaw Gruszka <stf_xl@wp.pl>,
Helmut Schaa <helmut.schaa@googlemail.com>,
Johannes Berg <johannes.berg@intel.com>
Subject: Re: [Regression] rt2800usb - Wifi performance issues and connection drops
Date: Sun, 12 Mar 2023 09:58:23 +0100 [thread overview]
Message-ID: <a917ba35-bba4-9741-b7d4-c6ec4dfec4a0@nbd.name> (raw)
In-Reply-To: <f00171a1-7f6f-d708-9587-4f176457fdfd@wetzel-home.de>
On 11.03.23 22:26, Alexander Wetzel wrote:
> Serialization helps. A (crude and in multiple ways incorrect) patch
> preventing two drv_wake_tx_queue() running for the same ac fixed the
> issue for Thomas:
> https://bugzilla.kernel.org/show_bug.cgi?id=217119#c20
>
> So it looks like we'll now have soon a fix for the issue.
>
> The driver wakes the queue for IEEE80211_AC_BE often for only a single
> skb and then stops it again.
> The short run time is insufficient for wake_txqs_tasklet to proper wake
> all queues itself and from time to time a new TX operation squeezes in
> after IEEE80211_AC_BE has been unblocked but prior of drv_wake_tx_queue
> being called from the wake_txqs_tasklet. When this happens
> drv_wake_tx_queue is called two times: Once from the tasklet, once from
> the userspace.
>
> ieee80211_handle_wake_tx_queue is using ieee80211_txq_schedule_start,
> which has this documented requirement:
> "The driver must not call multiple TXQ scheduling rounds concurrently."
> Now I don't think that is causing the reported regression. Nevertheless
> we should prevent concurrent calls of ieee80211_handle_wake_tx_queue for
> that reason alone.
>
> The real reason of the hangs is probably in the rt2800usb driver or
> hardware. I don't see anything in the driver code, so probably the HW
> itself has a problem with the two near-concurrent TX operations.
>
> The real culprit of the regression should be commit a790cc3a4fad ("wifi:
> mac80211: add wake_tx_queue callback to drivers"), which switched
> rt2800usb over to iTXQs. But without the fix from commit 4444bc2116ae
> ("wifi: mac80211: Proper mark iTXQs for resumption") mac80211 omitted to
> schedule the required run of the wake_txqs_tasklet. Thus thus instead of
> two concurrent drv_wake_tx_queue we only got one and the driver
> continued to work.
>
> I asked Thomas on bugzilla to test the "best" solution I came up with.
>
> There seems to be multiple ways. But I can't find a simple, low risk and
> complete fix. So I compromised...
>
> When Thomas can confirm the fix we can soon discuss the fix on
> linux-wireless.
I would recommend the following approach for properly fixing this issue:
On init if the .wake_tx_queue op is set to
ieee80211_handle_wake_tx_queue, create a single kthread that iterates
over all hw queues and schedules each one of them like
ieee80211_handle_wake_tx_queue does now.
Change ieee80211_handle_wake_tx_queue to simply schedule the kthread
without doing anything else.
This is how mt76 handles tx scheduling in the driver, and it works quite
well.
- Felix
next prev parent reply other threads:[~2023-03-12 8:58 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-04 16:24 Linux regression tracking (Thorsten Leemhuis)
2023-03-05 17:25 ` Thorsten Leemhuis
2023-03-05 22:05 ` Alexander Wetzel
2023-03-07 20:54 ` Alexander Wetzel
2023-03-07 22:31 ` Thomas Mann
2023-03-08 7:13 ` Alexander Wetzel
2023-03-08 10:26 ` Thomas Mann
2023-03-08 12:10 ` Alexander Wetzel
2023-03-08 12:29 ` Thomas Mann
2023-03-08 7:52 ` Felix Fietkau
2023-03-08 11:41 ` Alexander Wetzel
2023-03-08 11:57 ` Felix Fietkau
2023-03-08 12:21 ` Linux regression tracking (Thorsten Leemhuis)
2023-03-08 16:50 ` Alexander Wetzel
2023-03-09 7:59 ` Linux regression tracking (Thorsten Leemhuis)
2023-03-09 22:13 ` Alexander Wetzel
2023-03-11 21:26 ` Alexander Wetzel
2023-03-12 8:58 ` Felix Fietkau [this message]
2023-03-09 17:00 ` Alexander Wetzel
2023-03-09 17:29 ` Thomas Mann
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=a917ba35-bba4-9741-b7d4-c6ec4dfec4a0@nbd.name \
--to=nbd@nbd.name \
--cc=alexander@wetzel-home.de \
--cc=helmut.schaa@googlemail.com \
--cc=johannes.berg@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=rauchwolke@gmx.net \
--cc=regressions@lists.linux.dev \
--cc=stf_xl@wp.pl \
/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
all inboxes | Powered by JetHome®