mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Luka Gejak" <luka.gejak@linux.dev>
To: "Ping-Ke Shih" <pkshih@realtek.com>, "Luka Gejak" <luka.gejak@linux.dev>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Michael Straube" <straube.linux@gmail.com>,
	"Peter Robinson" <pbrobinson@gmail.com>,
	"Bitterblue Smith" <rtl8821cerfe2@gmail.com>
Subject: Re: [PATCH v11 4/7] wifi: rtw88: sdio: zero the padding added to a TX transfer
Date: Fri, 11 Sep 2026 09:40:55 +0200	[thread overview]
Message-ID: <DLCBFNKN09SW.2SIEDXTB4PGJD@linux.dev> (raw)
In-Reply-To: <a17a665d7d4c47fbb33e038d122ed200@realtek.com>

On Fri Sep 11, 2026 at 2:53 AM CEST, Ping-Ke Shih wrote:
> Ping-Ke Shih <pkshih@realtek.com> wrote:
>> Luka Gejak <luka.gejak@linux.dev> wrote:
>> > mac80211 reserves IEEE80211_ENCRYPT_TAILROOM, 18 bytes, and offers
>> > no way for a driver to ask for more on TX; extra_tx_headroom is headroom
>> > and extra_beacon_tailroom is beacons only.
>> 
>> You can modify mac80211 to reserve larger ndev->needed_tailroom to
>> see if it can really resolve the symptom. If so, you can propose
>> to add fields for tailroom like headroom:
>> 
>>   struct ieee80211_hw:: extra_tx_tailroom
>>   struct ieee80211_local:: tx_headroom
>> 
>
> Note that the ndev->needed_tailroom isn't guaranteed by comments, so doing
> some experiments by normal use case would be helpful to know if it's worth.
>
>  *	@needed_tailroom: Extra tailroom the hardware may need, but not in all
>  *			  cases can this be guaranteed. Some cases also use
>  *			  LL_MAX_HEADER instead to allocate the skb
>
> Ping-Ke

I ran it: one line in net/mac80211/iface.c, IEEE80211_ENCRYPT_TAILROOM
+ 512, nothing else. It does not help. Over 60000 frames the average
tailroom went from 106 to 139 bytes against an average pad of 469, and
96% still reallocate.

Your caveat is why, and it is stronger than the comment suggests:
mac80211 never reads ndev->needed_tailroom as the field appears once in
net/mac80211, which is the assignment itself. The only code that acts on
it is skb_ensure_writable_head_tail(), whose one caller is net/dsa/user.c.
And the protocols that do honour it read it when they allocate, which TCP
never does, which is why only the few non-TCP frames moved the average.

So that tested the wrong knob rather than the idea.

Your fields do work. I built them and measured it. ieee80211_skb_resize()
is the only place on the TX path that grows tailroom, and it derives
tail_need from IEEE80211_ENCRYPT_TAILROOM alone, gated on the frame
needing software crypto tailroom, which is false for data frames under
hardware CCMP. The headroom side is already what you describe:
hw.extra_tx_headroom folds into local->tx_headroom and both callers add
it into head_need. Adding hw.extra_tx_tailroom, folding it into a new
local->tx_tailroom and adding that to tail_need outside the crypto gate
delivers the tailroom. One further piece is needed: ieee80211_build_hdr()
skips the resize entirely when it wants no headroom and the skb is not
cloned, so that condition has to widen as well.

With the driver asking for one SDIO block, frames arriving short of
tailroom go from 29056 in 30000 to 1 in 30000, and uplink is about 6%
faster in an interleaved A/B.

One caveat though: this does not remove the reallocation, it moves it.
pskb_expand_head() is called just as often, from ieee80211_skb_resize()
now instead of from __skb_pad() in the driver. The driver side becomes
much cheaper, 445 ms of __skb_pad per 20 s run against 82 ms, and total
time in pskb_expand_head falls by about a third, but whole system CPU
does not drop. The gain looks like moving the work off the SDIO critical
path rather than doing less of it.

I can write that up for Johannes as a separate mac80211 patch, with the
rtw88 side as a follow up. It is independent of this series, but considering
your question was about CPU usage and this change doesn't overall reduce it,
it is probably not worth it.

Best regards,
Luka Gejak

  reply	other threads:[~2026-09-11  7:41 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-09  7:45 [PATCH v11 0/7] wifi: rtw88: preparations for RTL8723B/RTL8723BS luka.gejak
2026-09-09  7:45 ` [PATCH v11 1/7] wifi: rtw88: add the RTL8723B chip type and SDIO helper luka.gejak
2026-09-09  7:45 ` [PATCH v11 2/7] wifi: rtw88: rx: mark zero length packets on RTL8723BS luka.gejak
2026-09-09  7:45 ` [PATCH v11 3/7] wifi: rtw88: tx: extend the TX report purge timeout to RTL8723BS luka.gejak
2026-09-09  7:45 ` [PATCH v11 4/7] wifi: rtw88: sdio: zero the padding added to a TX transfer luka.gejak
2026-09-10  2:24   ` Ping-Ke Shih
2026-09-10 14:56     ` Luka Gejak
2026-09-10 15:51       ` Luka Gejak
2026-09-11  0:45         ` Ping-Ke Shih
2026-09-11  0:53           ` Ping-Ke Shih
2026-09-11  7:40             ` Luka Gejak [this message]
2026-09-11  7:45               ` Ping-Ke Shih
2026-09-11  8:42                 ` Luka Gejak
2026-09-11  0:30       ` Ping-Ke Shih
2026-09-11  6:41         ` Luka Gejak
2026-09-09  7:45 ` [PATCH v11 5/7] wifi: rtw88: sdio: track free TX pages and OQT credits for RTL8723BS luka.gejak
2026-09-10  2:40   ` Ping-Ke Shih
2026-09-09  7:45 ` [PATCH v11 6/7] wifi: rtw88: sdio: set up RX aggregation and interrupts " luka.gejak
2026-09-09  7:45 ` [PATCH v11 7/7] wifi: rtw88: sdio: add TX back-pressure and retry on page starvation 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=DLCBFNKN09SW.2SIEDXTB4PGJD@linux.dev \
    --to=luka.gejak@linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=pbrobinson@gmail.com \
    --cc=pkshih@realtek.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

all inboxes | Powered by JetHome®