Message-ID: <779092239.3209937.1703118406743@mail.yahoo.com>
Date: Thu, 21 Dec 2023 00:26:46 +0000 (UTC)
From: Household Cang <canghousehold@....com>
To: "davem@...emloft.net" <davem@...emloft.net>, 
	"rk.code@...look.com" <rk.code@...look.com>, 
	"sashal@...nel.org" <sashal@...nel.org>, 
	Jacob Keller <jacob.e.keller@...el.com>, 
	"alexandre.torgue@...s.st.com" <alexandre.torgue@...s.st.com>, 
	"joabreu@...opsys.com" <joabreu@...opsys.com>, 
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: RK3658 DSA Port to MT7531 TCP Checksum Offload Issue

Sorry, did not realize someone prefers to use plaintext email. Will resend in plaintext.


On Wednesday, December 20, 2023 at 04:25:03 PM EST, Household Cang <canghousehold@....com> wrote: 


Thanks.
I will add the appropriate maintainers to the list.

Btw, during my investigation, the issue is very reminiscent of https://www.intel.com/content/www/us/en/download/19174/disabling-tcp-ipv6-checksum-offload-capability-with-intel-1-10-gbe-controllers.html, with Nokia ONT used by Verizon. It seems the ONT was appending bits at the end of the packet it processes to cause a checksum mismatch. I have yet to confirm with Verizon engineering.

-----
For my issue, to undo the stmmac patches, then re-compile is a very tedious feat, especially it is a kernel jump from 6.1.1 to 6.6.0.
I have yet to conclude whether it is due to the stmmac driver or the MT7531 driver.

I read MT7531's datasheet and it appears the chip does not handle TCP checksum offloading.
So it may more likely point to stmmac is unable to handle something extra appended by MT7531 during the passage from DSA ports to the CPU port.

For the stmmac maintainers, could they point me to any specific patches that change the behavior of TCP checksum offloading, in the past year/9 months or so?

Thanks.
Lucas.




 On Wednesday, December 20, 2023 at 04:00:50 PM EST, Jacob Keller <jacob.e.keller@...el.com> wrote:


On 12/20/2023 11:41 AM, Household Cang wrote:
> Dear all,
> I applied Linux kernel 6.6.0 (yesterday) from 6.1.1 (snapshot from October of 2022), and suddenly the RK3568 is not reachable via SSH.An investigation shows the issue is restricted to stmmac-0:00 (SoC GMAC0, eth1), connected to DSA switch MT7531, and on TCP connections only. TCP connection captured in wireshark shows all retransmissions.
> Running ethtool -K eth1 (GMAC0 to MT7531 CPU port) rx off tx off fixes the TCP connection issue.t> Issue is not exhibited on eth0 directly exposed to RTL8211F PHY without passing through the DSA switch. TCP checksum offloading remains ON on eth0.eth0 and eth1 using stmmac. eth1 using mt7530-mdio to drive 4 DSA ports (lan0-3).

> Whether this issue is due to changes in the stmmac driver or the mt7530-mdio driver, or a combination of both?Is MT7531BE capable of handling TCP checksum offloading?For GMAC1 (eth0), the GMAC seems to handle the tcp-checksum offloading.For GMAC0 (eth1), I don't know whether MT7531 is capable of handling tcp-checksum as well?
> OR, could it be the something changed in stmmac driver that fails to account that frames coming from the DSA switch will bear extra tags?
> Thanks.Lucas.
> Excuse me if this is not the correct forum, but please do point me to the correct one...

Sounds like you might want to report this the stmmac folks, which
according to MAINTAINERS would be:

STMMAC ETHERNET DRIVER
M:      Alexandre Torgue <alexandre.torgue@...s.st.com>
M:      Jose Abreu <joabreu@...opsys.com>
L:      netdev@...r.kernel.org
S:      Supported
W:      http://www.stlinux.com
F:      Documentation/networking/device_drivers/ethernet/stmicro/
F:      drivers/net/ethernet/stmicro/stmmac/


If you have some experience building the kernel you could also try git
bisect to see if you could identify when it stopped working.

Hope this helps.


Thanks,

Jake

Powered by blists - more mailing lists