[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aLlq79or3c3brul_@shredder>
Date: Thu, 4 Sep 2025 13:33:19 +0300
From: Ido Schimmel <idosch@...sch.org>
To: Ricard Bejarano <ricard@...arano.io>
Cc: Andrew Lunn <andrew@...n.ch>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
netdev@...r.kernel.org, michael.jamet@...el.com,
YehezkelShB@...il.com, andrew+netdev@...n.ch, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com
Subject: Re: Poor thunderbolt-net interface performance when bridged
On Thu, Sep 04, 2025 at 10:56:29AM +0200, Ricard Bejarano wrote:
> My assumption was that, due to CRC checksum failures causing L2 loss at every
> rx end, and because of TCP congestion control back-off, TCP bandwidth drops
> exponentially with the number of hops.
> So the problem is not so much the TCP vs. UDP bandwidth, but the L2 loss
> caused by CRC errors. That L2 loss happens at the rx end because that's when
> CRC checksums are checked and frames are dropped, but other than cable
> problems I can only assume that's a bug in the tx end driver.
> I believe that's why Andrew Lunn pointed at the driver's handling of SKBs with
> fragments as the possible culprit, but the fix breaks the test completely.
If you suspect driver/hardware problems, you can try to disable features
that the driver claims to support and see what helps. You can start by
disabling all of them, see if it works and then try to pinpoint the
actual culprit.
ethtool -K tb0 tcp-segmentation-offload off
ethtool -K tb0 scatter-gather off
ethtool -K tb0 tx-checksum-ipv4 off
ethtool -K tb0 tx-checksum-ipv6 off
I think this should cover it, but you can check the output of "ethtool -k"
and see if there are other hardware related features that are still
enabled.
Powered by blists - more mailing lists