<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<p class="elementToProof" style="margin-top: 0px; margin-bottom: 0px;"><span style="letter-spacing: normal; font-family: Söhne, ui-sans-serif, system-ui, -apple-system, "Segoe UI", Roboto, Ubuntu, Cantarell, "Noto Sans", sans-serif, "Helvetica Neue", Arial, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; font-size: 16px; font-weight: 400; color: rgb(55, 65, 81);">Dear
community collaborators,</span></p>
<p style="text-align: left; margin: 1.25em 0px; border-width: 0px; border-style: solid; border-color: rgb(217, 217, 227);">
<span style="letter-spacing: normal; font-family: Söhne, ui-sans-serif, system-ui, -apple-system, "Segoe UI", Roboto, Ubuntu, Cantarell, "Noto Sans", sans-serif, "Helvetica Neue", Arial, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; font-size: 16px; font-weight: 400; color: rgb(55, 65, 81);">First
of all, I would like to thank you for the prompt response and the suggestions provided.</span></p>
<p style="text-align: left; margin: 1.25em 0px; border-width: 0px; border-style: solid; border-color: rgb(217, 217, 227);">
<span style="letter-spacing: normal; font-family: Söhne, ui-sans-serif, system-ui, -apple-system, "Segoe UI", Roboto, Ubuntu, Cantarell, "Noto Sans", sans-serif, "Helvetica Neue", Arial, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; font-size: 16px; font-weight: 400; color: rgb(55, 65, 81);">We
conducted the tests as indicated, but unfortunately, the problem persists. It seems to me that if it were a Checksum-related issue, the behavior would be different, as the VPN and communication work normally for several days before failing suddenly.</span></p>
<p style="text-align: left; margin: 1.25em 0px; border-width: 0px; border-style: solid; border-color: rgb(217, 217, 227);">
<span style="letter-spacing: normal; font-family: Söhne, ui-sans-serif, system-ui, -apple-system, "Segoe UI", Roboto, Ubuntu, Cantarell, "Noto Sans", sans-serif, "Helvetica Neue", Arial, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; font-size: 16px; font-weight: 400; color: rgb(55, 65, 81);">We
have observed that the only effective ways to reestablish communication, so far, are through a system reboot or by changing the authentication cipher, such as switching from MD5 to SHA1. Interestingly, when switching back to the MD5 cipher, the communication
fails to function again.</span></p>
<p style="text-align: left; margin: 1.25em 0px; border-width: 0px; border-style: solid; border-color: rgb(217, 217, 227);">
<span style="letter-spacing: normal; font-family: Söhne, ui-sans-serif, system-ui, -apple-system, "Segoe UI", Roboto, Ubuntu, Cantarell, "Noto Sans", sans-serif, "Helvetica Neue", Arial, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; font-size: 16px; font-weight: 400; color: rgb(55, 65, 81);">I
am immensely grateful for the help received so far and would greatly appreciate any further suggestions or recommendations that you might offer to resolve this challenge.</span></p>
<p style="text-align: left; margin: 1.25em 0px; border-width: 0px; border-style: solid; border-color: rgb(217, 217, 227);" class="elementToProof">
<span style="letter-spacing: normal; font-family: Söhne, ui-sans-serif, system-ui, -apple-system, "Segoe UI", Roboto, Ubuntu, Cantarell, "Noto Sans", sans-serif, "Helvetica Neue", Arial, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; font-size: 16px; font-weight: 400; color: rgb(55, 65, 81);">Sincerely,</span></p>
<div id="appendonsend"></div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<hr style="display: inline-block; width: 98%;">
<div id="divRplyFwdMsg" dir="ltr"><span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"><b>De:</b> Vladimir Oltean <olteanv@gmail.com><br>
<b>Enviado:</b> sexta-feira, 22 de dezembro de 2023 09:30<br>
<b>Para:</b> Household Cang <canghousehold@aol.com><br>
<b>Cc:</b> 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 <netdev@vger.kernel.org>; linux-stm32@st-md-mailman.stormreply.com <linux-stm32@st-md-mailman.stormreply.com>; linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org><br>
<b>Assunto:</b> Re: [PATCH net 0/1] Prevent DSA tags from breaking COE</span>
<div> </div>
</div>
<div><span style="font-size: 11pt;">Hi Lucas,<br>
<br>
On Thu, Dec 21, 2023 at 02:40:34AM -0500, Household Cang wrote:<br>
> > On Dec 18, 2023, at 11:23 AM, Romain Gantois <romain.gantois@bootlin.com> wrote:<br>
> ><br>
> > This is a bugfix for an issue that was recently brought up in two<br>
> > reports:<br>
> ><br>
> > <a href="https://lore.kernel.org/netdev/c57283ed-6b9b-b0e6-ee12-5655c1c54495@bootlin.com/" id="OWAe7ccc5f7-11c1-265c-11c3-a2b0078e3893" class="OWAAutoLink" data-auth="NotApplicable">
https://lore.kernel.org/netdev/c57283ed-6b9b-b0e6-ee12-5655c1c54495@bootlin.com/</a><br>
> > <a href="https://lore.kernel.org/netdev/e5c6c75f-2dfa-4e50-a1fb-6bf4cdb617c2@electromag.com.au/" id="OWA98dd2bb6-a728-89ce-9b82-e736c8c3a1b3" class="OWAAutoLink" data-auth="NotApplicable">
https://lore.kernel.org/netdev/e5c6c75f-2dfa-4e50-a1fb-6bf4cdb617c2@electromag.com.au/</a><br>
> ><br>
> Add me in to be the 3rd report...<br>
> RK3568 GMAC0 (eth1) to MT7531BE (CPU port)<br>
> Current workaround for me is ethtool -K eth1 rx off tx off<br>
<br>
Is "rx off" actually required, or just "tx off"?<br>
<br>
> <a href="https://lore.kernel.org/netdev/m3clft2k7umjtny546ot3ayebattksibty3yyttpffvdixl65p@7dpqsr5nisbk/T/#t" id="OWA6dd821ba-da59-5b50-7600-b71070bc3379" class="OWAAutoLink" data-auth="NotApplicable">
https://lore.kernel.org/netdev/m3clft2k7umjtny546ot3ayebattksibty3yyttpffvdixl65p@7dpqsr5nisbk/T/#t</a><br>
><br>
> Question on the patch to be built: how would I know if my setup could<br>
> take advantage of the HW checksum offload? RK3658’s eth0 on stmmac is<br>
> doing fine, and eth0 is not on a DSA switch. Does this mean eth1<br>
> should be able to do hw checksum offload once the stmmac driver is<br>
> fixed?<br>
<br>
The MT7531BE switch requires transmitted packets to have an additional<br>
header which indicates what switch port is targeted. So the packet<br>
structure is not the same as what eth0 transmits.<br>
<br>
Your GMAC datasheet should explain what packets it is able to offload<br>
L4 checksumming for, quite plainly. Probably MAC + IP + TCP yes, but<br>
MAC + MTK DSA + IP + TCP no.<br>
<br>
The bug is that the network stack thinks that the GMAC is able to<br>
offload TX checksums for these MTK DSA tagged packets, so it does not<br>
calculate the checksum in software, leaving the task up to the hardware.<br>
My guess is that the hardware doesn't recognize the packets as something<br>
that is offloadable, so it doesn't calculate the checksum either, and<br>
that's the story of how you end up with packets with bad checksums.<br>
<br>
The patch to be built should analyze the packet before passing it to a<br>
hardware offload engine which will do nothing. The driver still declares<br>
the NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM features because it is able to<br>
offload checksumming for _some_ packets, but it falls back to the<br>
software checksum helper for the rest. This includes your MTK DSA tagged<br>
packets. They can be checksummed in software even with the DSA tag added,<br>
because that uses the more generic mechanism with skb->csum_start and<br>
skb->csum_offset, which DSA is compatible with, just fine. The GMAC<br>
driver, most likely because of the lack of hardware support, does not<br>
look at skb->csum_start and skb->csum_offset (aka it does not declare<br>
the NETIF_F_HW_CSUM feature), so it cannot offload checksumming for your<br>
switch traffic unless that was specifically baked into the RTL.<br>
<br>
More details in the "Switch tagging protocols" section of<br>
Documentation/networking/dsa/dsa.rst.<br>
<br>
</span></div>
</body>
</html>