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: <63FE081D-44C9-47EC-BEDF-2965C023C43E@bejarano.io>
Date: Tue, 27 May 2025 10:47:09 +0200
From: Ricard Bejarano <ricard@...arano.io>
To: Andrew Lunn <andrew@...n.ch>
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

> 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.

Right, here you go.

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?

Thanks,
Ricard Bejarano