netdev - Re: Poor thunderbolt-net interface performance when bridged

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9a5f7f4c-268f-4c7c-b033-d25afc76f81c@lunn.ch>
Date: Mon, 26 May 2025 22:19:56 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Ricard Bejarano <ricard@...arano.io>
Cc: 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 Mon, May 26, 2025 at 09:34:19PM +0200, Ricard Bejarano wrote:
> Hey Andrew, thanks for chiming in.
> 
> > Do the interfaces provide statistics? ethtool -S. Where is the packet
> > loss happening?
> 
> root@...e:~# ethtool -S tb0
> no stats available
> root@...e:~# ip -s link show tb0
> 6: tb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP mode DEFAULT group default qlen 1000
>     link/ether 02:70:19:dc:92:96 brd ff:ff:ff:ff:ff:ff
>     RX:  bytes packets errors dropped  missed   mcast
>       11209729   71010      0       0       0       0
>     TX:  bytes packets errors dropped carrier collsns
>      624522843  268941      0       0       0       0
> root@...e:~#
> 
> root@red:~# ethtool -S tb0
> no stats available
> root@red:~# ip -s link show tb0
> 8: tb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP mode DEFAULT group default qlen 1000
>     link/ether 02:5f:d6:57:71:93 brd ff:ff:ff:ff:ff:ff
>     RX:  bytes packets errors dropped  missed   mcast
>      624522843  320623      0       0       0       0
>     TX:  bytes packets errors dropped carrier collsns
>       11209729   71007      0       0       0       0
> root@red:~#

There are three devices in your chain, so three sets of numbers would
be good.

What is also interesting is not the absolute numbers, but the
difference after sending a known amount of packets.

So take a snapshot of all the numbers. Do a UDP stream. Take another
snapshot of the numbers and then a subtractions. You can then see how
many packets got launched into the chain, how many made it to the end
of the first link, how many got sent into the second link and how many
made it to the end of the chain. That should give you an idea where
the packets are getting lost.

> This is the first time we're going beyond ~5Mbps in the blue->purple direction,
> meaning, there is something up with TCP.

Not really. TCP does not work well on lossy links. TCP considers
packet loss as congestion, it is sending too fast for the link. So it
slows down. If there is a lot of packet loss, it just runs slow.

What you need to do is find out where the packet loss happens. Then
why the packet loss happens.

What you also might find interesting is
https://github.com/nhorman/dropwatch.

	Andrew