From: Romain Gantois <romain.gantois@bootlin.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Romain Gantois <romain.gantois@bootlin.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Jose Abreu <joabreu@synopsys.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Maxime Chevallier <maxime.chevallier@bootlin.com>,
Sylvain Girard <sylvain.girard@se.com>,
Pascal EBERHARD <pascal.eberhard@se.com>,
Richard Tresidder <rtresidd@electromag.com.au>,
netdev@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, stable@vger.kernel.org
Subject: Re: [PATCH net 1/1] net: stmmac: Prevent DSA tags from breaking COE
Date: Fri, 29 Dec 2023 17:11:48 +0100 (CET) [thread overview]
Message-ID: <3b53aa8a-73e9-9260-f05b-05dac80a4276@bootlin.com> (raw)
In-Reply-To: <20231219122034.pg2djgrosa4irubh@skbuf>
On Tue, 19 Dec 2023, Vladimir Oltean wrote:
> DSA_TAG_PROTO_LAN9303, DSA_TAG_PROTO_SJA1105 and DSA_TAG_PROTO_SJA1110
> construct tags with ETH_P_8021Q as EtherType. Do you still think it
> would be correct to say that all DSA tags break COE on the stmmac, as
> this patch assumes?
>
> The NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM convention is not about
> statically checking whether the interface using DSA, but about looking
> at each packet before deciding whether to use the offload engine or to
> call skb_checksum_help().
>
> You can experiment with any tagging protocol on the stmmac driver, and
> thus with the controller's response to any kind of traffic, even if the
> port is not attached to a hardware switch. You need to enable the
Thanks for telling me about DSA_LOOP, I've tested several DSA tagging protocols
with the RZN1 GMAC1 hardware using this method. Here's what I found in a
nutshell:
For tagging protocols that change the EtherType field in the MAC header (e.g.
DSA_TAG_PROTO_(DSA/EDSA/BRCM/MTK/RTL4C_A/SJA1105): On TX the tagged frames are
almost always ignored by the checksum offload engine and IP header checker of
the MAC device. I say "almost always" because there is an
unlikely but nasty corner case where a DSA tag can be identical to an IP
EtherType value. In these cases, the frame will likely fail IP header checks
and be dropped by the MAC.
Ignoring these corner cases, the DSA frames will egress with a partial
checksum and be dropped by the recipient. On RX, these frames will, once again,
not be detected as IP frames by the MAC. So they will be transmitted to the CPU.
However, the stmmac driver will assume (wrongly in this case) that
these frames' checksums have been verified by the MAC. So it will set
CHECKSUM_UNECESSARY:
https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c#L5493
And so the IP/TCP checksums will not be checked at all,
which is not ideal.
There are other DSA tagging protocols which cause different issues. For example
DSA_TAG_PROTO_BRCM_PREPEND, which seems to offset the whole MAC header, and
DSA_TAG_PROTO_LAN9303 which sets ETH_P_8021Q as its EtherType. I haven't dug too
deeply on these issues yet, since I'd rather deal with the checksumming issue
before getting distracted by VLAN offloading and other stuff.
Among the tagging protocols I tested, the only one that didn't cause any issues
was DSA_TAG_PROTO_TRAILER, which only appends stuff to the frame.
TLDR: The simplest solution seems to be to modify the stmmac TX and RX paths to
disable checksum offloading for frames that have a non-IP ethertype in
their MAC header. This will fix the checksum situation for DSA tagging protocols
that set non-IP and non-8021Q EtherTypes. Some edge cases like
DSA_TAG_PROTO_BRCM_PREPEND and DSA_TAG_PROTO_LAN9303 will require a completely
different solution if we want these MAC devices to handle them properly.
Please share any thoughts you might have on this suggestion.
Best Regards,
--
Romain Gantois, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2023-12-29 16:22 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-18 16:23 [PATCH net 0/1] Prevent DSA tags from breaking COE Romain Gantois
2023-12-18 16:23 ` [PATCH net 1/1] net: stmmac: " Romain Gantois
2023-12-19 12:20 ` Vladimir Oltean
2023-12-19 13:07 ` Maxime Chevallier
2023-12-19 14:19 ` Linus Walleij
2023-12-19 16:29 ` Maxime Chevallier
2023-12-19 22:46 ` Vladimir Oltean
2023-12-20 0:43 ` Linus Walleij
2023-12-20 23:00 ` Linus Walleij
2023-12-29 16:11 ` Romain Gantois [this message]
2023-12-30 14:17 ` Vladimir Oltean
2023-12-18 16:41 ` [PATCH net 0/1] " Andrew Lunn
2023-12-19 9:50 ` Romain Gantois
2024-01-05 4:37 ` Richard Tresidder
2023-12-19 12:30 ` Vladimir Oltean
2023-12-21 7:40 ` Household Cang
2023-12-22 12:30 ` Vladimir Oltean
2023-12-22 13:22 ` Lucas Pereira
2023-12-22 13:46 ` Vladimir Oltean
2023-12-22 19:08 ` Household Cang
[not found] ` <SJ2PR22MB45547404DA1CA10A201B2BE0A294A@SJ2PR22MB4554.namprd22.prod.outlook.com>
2025-10-17 6:56 ` Proxy ARP NetNS Awareness Household Cang
2025-10-20 9:58 ` Nicolas Dichtel
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=3b53aa8a-73e9-9260-f05b-05dac80a4276@bootlin.com \
--to=romain.gantois@bootlin.com \
--cc=alexandre.torgue@foss.st.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=joabreu@synopsys.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=maxime.chevallier@bootlin.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=miquel.raynal@bootlin.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=pascal.eberhard@se.com \
--cc=rtresidd@electromag.com.au \
--cc=stable@vger.kernel.org \
--cc=sylvain.girard@se.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