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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <0b6cf76d-e64d-4a35-b006-20946e67da6e@lunn.ch>
Date: Tue, 27 May 2025 14:51:29 +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

> root@red:~# iperf3 -c 10.0.0.2 -u -b 1100M -t 5  # blue
> Connecting to host 10.0.0.2, port 5201
> [  5] local 10.0.0.1 port 46140 connected to 10.0.0.2 port 5201
> [ ID] Interval           Transfer     Bitrate         Total Datagrams
> [  5]   0.00-1.00   sec   131 MBytes  1.10 Gbits/sec  94897
> [  5]   1.00-2.00   sec   131 MBytes  1.10 Gbits/sec  94959
> [  5]   2.00-3.00   sec   131 MBytes  1.10 Gbits/sec  94959
> [  5]   3.00-4.00   sec   131 MBytes  1.10 Gbits/sec  94959
> [  5]   4.00-5.00   sec   131 MBytes  1.10 Gbits/sec  94951
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
> [  5]   0.00-5.00   sec   656 MBytes  1.10 Gbits/sec  0.000 ms  0/474725 (0%)  sender
> [  5]   0.00-5.00   sec   597 MBytes  1.00 Gbits/sec  0.004 ms  42402/474725 (8.9%)  receiver
> root@red:~#
> 
> Here are the stat diffs for each interface:
> 
> 1) red's br0 (10.0.0.1)
>     RX:    bytes  packets errors dropped  missed   mcast
>            +1055      +14      -       -       -       -
>     TX:    bytes  packets errors dropped carrier collsns
>       +707341722  +474740      -       -       -       -
> 
> 2) red's tb0
>     RX:    bytes  packets errors dropped  missed   mcast
>            +1251      +14      -       -       -       -
>     TX:    bytes  packets errors dropped carrier collsns
>       +707341722  +474740      -       -       -       -
> 
> 3) blue's tb0
>     RX:    bytes  packets errors dropped  missed   mcast
>       +707028822  +474530     +5       -       -       -
>     TX:    bytes  packets errors dropped carrier collsns
>            +1251      +14      -       -       -       -
> 
> 4) blue's br0 (10.0.0.2)
>     RX:    bytes  packets errors dropped  missed   mcast
>       +700385402  +474530      -       -       -       -
>     TX:    bytes  packets errors dropped carrier collsns
>            +1251      +14      -       -       -       -
> 
> So, if I'm reading this right, loss happens at blue tb0 RX.
> We have 5 errors there and lost 210 packets.
> 
> Also, why does iperf3 report 42402 lost packets, though?

210 lost is probably not enough to cause the TCP issue. The difference
between 210 and 42402 probably means the loss is happening higher up
the stack. But the majority are reaching blue, and then getting
dropped. So maybe look at IP and UDP statistics, are the packets
corrupt, failing CRC errors? netstat(1) and ss(1) will help you.

Another thing to try is run tcpdump on blue can capture some of the
packets to a file. Feed the file to wireshark. Unlike tcpdump,
wireshark checks all the CRCs and will tell you if they are wrong.

	Andrew