From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Ricard Bejarano <ricard@bejarano.io>
Cc: netdev@vger.kernel.org, michael.jamet@intel.com,
YehezkelShB@gmail.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com
Subject: Re: Poor thunderbolt-net interface performance when bridged
Date: Mon, 26 May 2025 07:50:04 +0300 [thread overview]
Message-ID: <20250526045004.GL88033@black.fi.intel.com> (raw)
In-Reply-To: <353118D9-E9FF-4718-A33A-54155C170693@bejarano.io>
Hi,
On Fri, May 23, 2025 at 05:07:02PM +0200, Ricard Bejarano wrote:
> > What is the performance without bridging?
>
> I actually tested this as soon as I sent my original message. Interestingly
> enough, performance without bridging is about the same: ~930Mbps in the
> purple->red direction, ~5Mbps in red->purple.
>
> I also tested running eBPF/XDP programs attached to both eno1 and tb0 to
> immediately XDP_REDIRECT to each other. This worked, as confirmed by successful
> ping/iperf even after bringing br0 down, and I could see the XDP program
> invocation counts growing in 'bpftool prog list'.
> But all I got was maybe (IMO falls within measurement error margin) a ~1Mbps
> average increase in throughput in the red->purple direction.
> But I guess we've now isolated the problem out of the bridge completely, right?
>
> As instructured, I've attached the full 'dmesg' output after setting the
> 'thunderbolt.dyndbg=+p' kernel command line flag.
Thanks for the logs. See below my analysis.
> [ 4.144711] thunderbolt 0000:04:00.0: using firmware connection manager
This means the tunnels are controlled by firmware not the kernel driver.
E.g this is an older non-USB4 system. The firmware connection manager does
not support lane bonding whic means your link only can use the 20 Gb/s
single lane. However, there is even more to this:
> [ 5.497037] thunderbolt 0-1: current link speed 10.0 Gb/s
> [ 5.497049] thunderbolt 0-1: current link width symmetric, single lane
This one shows that the link was trained only to gen2. That's instead of 20
Gb/s you get only 10 Gb/s. Now since this if firmware the driver only logs
these but I suggest to check this by running:
# tblist -Av
You can get tbtools here [1].
Reason for this typically is bad cable. The ones that has the small
ligthning logo should work the best. If you use something else then the
link may get degraded. You can check the negotiated link speed running the
above command. I think this explains why you see the "low" throughput. Hope
this helps.
[1] https://github.com/intel/tbtools/wiki/Useful-Commands#list-all-devices-including-other-hosts-and-retimers
next prev parent reply other threads:[~2025-05-26 4:50 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-22 17:19 Poor thunderbolt-net interface performance when bridged Ricard Bejarano
2025-05-23 11:07 ` Mika Westerberg
2025-05-23 15:07 ` Ricard Bejarano
2025-05-26 4:50 ` Mika Westerberg [this message]
2025-05-26 8:50 ` Ricard Bejarano
2025-05-26 9:22 ` Mika Westerberg
2025-05-26 11:47 ` Ricard Bejarano
2025-05-26 12:04 ` Mika Westerberg
2025-05-26 16:10 ` Ricard Bejarano
2025-05-27 10:33 ` Mika Westerberg
2025-05-27 12:36 ` Ricard Bejarano
2025-05-26 14:28 ` Andrew Lunn
2025-05-26 15:09 ` Stephen Hemminger
2025-05-26 19:36 ` Ricard Bejarano
2025-05-26 19:34 ` Ricard Bejarano
2025-05-26 20:19 ` Andrew Lunn
2025-05-27 8:47 ` Ricard Bejarano
2025-05-27 12:51 ` Andrew Lunn
2025-05-27 14:25 ` Ricard Bejarano
2025-05-27 15:02 ` Andrew Lunn
2025-05-27 18:57 ` Ricard Bejarano
2025-05-27 19:08 ` Andrew Lunn
2025-05-27 19:17 ` Ricard Bejarano
2025-05-27 19:32 ` Ricard Bejarano
2025-05-28 6:38 ` Ricard Bejarano
2025-05-28 11:57 ` Andrew Lunn
2025-05-28 13:08 ` Ricard Bejarano
2025-05-29 12:45 ` Ricard Bejarano
2025-06-14 9:13 ` Ricard Bejarano
2025-06-14 14:11 ` Andrew Lunn
2025-06-15 13:56 ` Ricard Bejarano
2025-06-21 11:00 ` Ricard Bejarano
2025-06-30 7:28 ` Ricard Bejarano
2025-08-28 7:59 ` Ricard Bejarano
2025-09-01 20:20 ` Ido Schimmel
2025-09-02 10:18 ` Ricard Bejarano
2025-09-03 7:43 ` Ido Schimmel
2025-09-04 8:56 ` Ricard Bejarano
2025-09-04 10:33 ` Ido Schimmel
2025-05-29 8:38 ` Ricard Bejarano
2025-05-29 10:06 ` Ricard Bejarano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250526045004.GL88033@black.fi.intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=YehezkelShB@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=michael.jamet@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=ricard@bejarano.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.