From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-stm32@st-md-mailman.stormreply.com, netdev@vger.kernel.org,
Ong Boon Leong <boon.leong.ong@intel.com>,
Paolo Abeni <pabeni@redhat.com>
Subject: [PATCH net-next v2 00/14] net: stmmac: TSO fixes/cleanups
Date: Wed, 1 Apr 2026 08:20:52 +0100 [thread overview]
Message-ID: <aczHVF04LIGq_lYO@shell.armlinux.org.uk> (raw)
This is a more refined version of the previous patch series fixing
and cleaning up the TSO code.
I'm not sure whether "TSO" or "GSO" should be used to describe this
feature - although it primarily handles TCP, dwmac4 appears to also
be able to handle UDP.
In essence, this series adds a .ndo_features_check() method to handle
whether TSO/GSO can be used for a particular skbuff - checking which
queue the skbuff is destined for and whether that has TBS available
which precludes TSO being enabled on that channel.
I'm also adding a check that the header is smaller than 1024 bytes,
as documented in those sources which have TSO support - this is due
to the hardware buffering the header in "TSO memory" which I guess
is limited to 1KiB. I expect this test never to trigger, but if
the headers ever exceed that size, the hardware will likely fail.
While IPv4 headers are unlikely to be anywhere near this, there is
nothing in the protocol which prevents IPv6 headers up to 64KiB.
As we now have a .ndo_features_check() method, I'm moving the VLAN
insertion for TSO packets into core code by unpublishing the VLAN
insertion features when we use TSO. Another move is for checksumming,
which is required for TSO, but stmmac's requirements for offloading
checksums are more strict - and this seems to be a bug in the TSO
path.
I've changed the hardware initialisation to always enable TSO support
on the channels even if the user requests TSO/GSO to be disabled -
this fixes another issue as pointed out by Jakub in a previous review.
I'm moving the setup of the GSO features, cleaning those up, and
adding a warning if platform glue requests this to be enabled but the
hardware has no support. Hopefully this will never trigger if everyone
got the STMMAC_FLAG_TSO_EN flag correct. Also adding a check for TxPBL
value.
Finally, moving the "TSO supported" message to the new
stmmac_set_gso_features() function so keep all this TSO stuff together.
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 3 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 214 +++++++++++++++-------
2 files changed, 150 insertions(+), 67 deletions(-)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
next reply other threads:[~2026-04-01 7:21 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-01 7:20 Russell King (Oracle) [this message]
2026-04-01 7:21 ` [PATCH net-next v2 01/14] net: stmmac: fix channel TSO enable on resume Russell King (Oracle)
2026-04-01 7:21 ` [PATCH net-next v2 02/14] net: stmmac: fix .ndo_fix_features() Russell King (Oracle)
2026-04-01 7:21 ` [PATCH net-next v2 03/14] net: stmmac: fix TSO support when some channels have TBS available Russell King (Oracle)
2026-04-01 7:21 ` [PATCH net-next v2 04/14] net: stmmac: add stmmac_tso_header_size() Russell King (Oracle)
2026-04-01 7:21 ` [PATCH net-next v2 05/14] net: stmmac: add TSO check for header length Russell King (Oracle)
2026-04-01 7:21 ` [PATCH net-next v2 06/14] net: stmmac: add GSO MSS checks Russell King (Oracle)
2026-04-01 7:21 ` [PATCH net-next v2 07/14] net: stmmac: move TSO VLAN tag insertion to core code Russell King (Oracle)
2026-04-01 7:21 ` [PATCH net-next v2 08/14] net: stmmac: move check for hardware checksum supported Russell King (Oracle)
2026-04-01 7:21 ` [PATCH net-next v2 09/14] net: stmmac: simplify GSO/TSO test in stmmac_xmit() Russell King (Oracle)
2026-04-01 7:22 ` [PATCH net-next v2 10/14] net: stmmac: split out gso features setup Russell King (Oracle)
2026-04-01 7:22 ` [PATCH net-next v2 11/14] net: stmmac: make stmmac_set_gso_features() more readable Russell King (Oracle)
2026-04-01 7:22 ` [PATCH net-next v2 12/14] net: stmmac: add warning when TSO is requested but unsupported Russell King (Oracle)
2026-04-01 7:22 ` [PATCH net-next v2 13/14] net: stmmac: check txpbl for TSO Russell King (Oracle)
2026-04-01 7:22 ` [PATCH net-next v2 14/14] net: stmmac: move "TSO supported" message to stmmac_set_gso_features() Russell King (Oracle)
2026-04-01 12:19 ` [PATCH net-next v2 00/14] net: stmmac: TSO fixes/cleanups Andrew Lunn
2026-04-01 12:41 ` Russell King (Oracle)
2026-04-02 18:40 ` patchwork-bot+netdevbpf
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=aczHVF04LIGq_lYO@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew+netdev@lunn.ch \
--cc=andrew@lunn.ch \
--cc=boon.leong.ong@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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