From: Ping-Ke Shih <pkshih@realtek.com>
To: "luka.gejak@linux.dev" <luka.gejak@linux.dev>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Michael Straube" <straube.linux@gmail.com>,
Bitterblue Smith <rtl8821cerfe2@gmail.com>,
Peter Robinson <pbrobinson@gmail.com>,
"Hans de Goede" <johannes.goede@oss.qualcomm.com>
Subject: RE: [PATCH v8 6/6] wifi: rtw88: sdio: add TX back-pressure and retry on page starvation
Date: Fri, 28 Aug 2026 09:29:29 +0000 [thread overview]
Message-ID: <abbadda4537640eab1bce5620ade5f47@realtek.com> (raw)
In-Reply-To: <20260825163314.1590-7-luka.gejak@linux.dev>
luka.gejak@linux.dev <luka.gejak@linux.dev> wrote:
> From: Luka Gejak <luka.gejak@linux.dev>
>
> Two problems show up on RTL8723BS uplink. The per-AC software FIFO is
> unbounded, so mac80211 keeps handing frames down until latency collapses
> under load. And when a transfer cannot be completed the queue is simply
> abandoned for that pass, which stalls the AC until something else kicks
> the worker.
>
> Stop the mac80211 queue once a data AC fills past a high watermark and
> wake it from the drain path when it falls back to a low one. Both sides
> take the TX queue lock across the length check and the flag update, the
> way rtw_pci_tx_write() and rtw_pci_tx_isr() use irq_lock. Without it the
> producer could stop a queue on a length the drain path had already
> emptied, having seen the flag still clear and so skipped the wake, and
> the AC would have stayed stopped with nothing left to wake it.
>
> Convert the TX work item to a delayed work and re-arm it when a transfer
> fails for a reason that can clear on its own, so it is retried rather
> than the AC abandoned, and cancel the work on teardown.
>
> Retrying matters once the queue can be stopped. A stopped queue is
> handed no further frames, so nothing else would kick the worker, and the
> AC would stay stopped for good with the link still up and receive
> unaffected. The two retried cases, a transmit page or output queue
> shortage and a failed skb expansion, are also the two that fail
> silently; the rest are logged where they happen, so they are visible
> rather than an unexplained hang, and they keep the existing behaviour
> rather than being retried indefinitely.
>
> Measured on RTL8723BS hardware, uplink goes from 11.9 Mbit/s with 204
> TCP retransmits to 20.1 Mbit/s with 2.
>
> Signed-off-by: Luka Gejak <luka.gejak@linux.dev>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
The v8 is almost done. Only one small nit.
Since I don't test the RTL8723BS at all, please test it by yourself
carefully. At the last review (I think v9), I will focus on the changes
of this patchset doesn't affect existing chips.
next prev parent reply other threads:[~2026-08-28 9:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 16:33 [PATCH v8 0/6] wifi: rtw88: preparations for RTL8723B/RTL8723BS luka.gejak
2026-08-25 16:33 ` [PATCH v8 1/6] wifi: rtw88: add the RTL8723B chip type and SDIO helper luka.gejak
2026-08-25 16:33 ` [PATCH v8 2/6] wifi: rtw88: rx: mark zero length packets on RTL8723BS luka.gejak
2026-08-25 16:33 ` [PATCH v8 3/6] wifi: rtw88: tx: extend the TX report purge timeout to RTL8723BS luka.gejak
2026-08-25 16:33 ` [PATCH v8 4/6] wifi: rtw88: sdio: track free TX pages and OQT credits for RTL8723BS luka.gejak
2026-08-28 9:23 ` Ping-Ke Shih
2026-08-28 9:40 ` Luka Gejak
2026-08-25 16:33 ` [PATCH v8 5/6] wifi: rtw88: sdio: set up RX aggregation and interrupts " luka.gejak
2026-08-25 16:33 ` [PATCH v8 6/6] wifi: rtw88: sdio: add TX back-pressure and retry on page starvation luka.gejak
2026-08-28 9:29 ` Ping-Ke Shih [this message]
2026-08-28 9:47 ` Luka Gejak
2026-08-26 17:53 ` [PATCH v8 0/6] wifi: rtw88: preparations for RTL8723B/RTL8723BS Luka Gejak
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=abbadda4537640eab1bce5620ade5f47@realtek.com \
--to=pkshih@realtek.com \
--cc=johannes.goede@oss.qualcomm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=luka.gejak@linux.dev \
--cc=pbrobinson@gmail.com \
--cc=rtl8821cerfe2@gmail.com \
--cc=straube.linux@gmail.com \
/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