From: Ping-Ke Shih <pkshih@realtek.com>
To: Devin Wittmayer <lucid_duck@justthetip.ca>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
Bitterblue Smith <rtl8821cerfe2@gmail.com>,
Nick Morrow <morrownr@gmail.com>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: RE: [PATCH rtw-next] wifi: rtw89: usb: shorten the RX aggregation hold on RTL8922AU
Date: Wed, 7 Oct 2026 02:31:24 +0000 [thread overview]
Message-ID: <ab97da288acb477e91484f1461632b26@realtek.com> (raw)
In-Reply-To: <20261006190618.258037-1-lucid_duck@justthetip.ca>
Devin Wittmayer <lucid_duck@justthetip.ca> wrote:
> The RTL8922AU holds received frames for up to a millisecond before
> handing them to the host, a value carried over from the RTL8852CU.
> That adds up to a millisecond of round trip, and under load at 160 MHz
> the access point drops to lower rates and download suffers.
>
> Shorten the hold on this chip. Upload is unchanged, and so is download
> on a USB 2 port, where the bus is the limit.
Can I know the number of USB 2 port? Just curious, not blocking item.
> The cost is some extra CPU at the same load.
I think the major reason people want RX aggregation is that a chip is
operating on a low-end CPU.
>
> RTL8922AU on USB 3 at 160 MHz, power save off for the round trip:
>
> x86, 6 GHz x86, 5 GHz Pi 5, 6 GHz
> before after before after before after
> TCP down, 1 flow 613 1002 579 948 586 999 Mbps
> TCP down, 8 flows 656 1187 629 1080 605 1108 Mbps
> round trip 2.33 1.29 2.25 1.18 1.44 0.88 ms
> busiest core, UDP 200M 8.4 12.8 8.3 12.9 2.3 2.8 %
>
> Fixes: 32cee8a9bb66 ("wifi: rtw89: usb: Enable RX aggregation for RTL8922AU")
> Reported-by: Nick Morrow <morrownr@gmail.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
> ---
> Ping-Ke, Bitterblue pointed me to you, since the 32 came from Realtek.
> Realtek's 8852CU driver uses it as the default and also has a
> small-packet mode that sets the hold to 1, the value this patch uses.
> If the longer default is there for a reason these tests would miss,
> please let me know, thank you.
I can't find small-packet mode you mentioned, please share a link.
As I know the reason of longer default can benefit low-end CPU.
By the way, the TX aggregation is pending, because our experiments
show no gain after the patch, so I don't send the patch. That means
current platform is much better than what years ago.
Ping-Ke
prev parent reply other threads:[~2026-10-07 2:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-06 19:06 [PATCH rtw-next] wifi: rtw89: usb: shorten the RX aggregation hold on RTL8922AU Devin Wittmayer
2026-10-07 2:31 ` Ping-Ke Shih [this message]
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=ab97da288acb477e91484f1461632b26@realtek.com \
--to=pkshih@realtek.com \
--cc=linux-wireless@vger.kernel.org \
--cc=lucid_duck@justthetip.ca \
--cc=morrownr@gmail.com \
--cc=rtl8821cerfe2@gmail.com \
--cc=stable@vger.kernel.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.