From: Yachen Liu <blankwonder@gmail.com>
To: netdev@vger.kernel.org
Cc: michael.jamet@intel.com, mika.westerberg@linux.intel.com,
YehezkelShB@gmail.com
Subject: [Bug][USB4NET] Potential Bug with USB4NET and Linux Bridging
Date: Thu, 14 Sep 2023 22:02:24 +0800 [thread overview]
Message-ID: <CAPsLH6aHJGG7kAaZ7hdyKoSor4Ws2Fwujjjxog6E_bQrY1fA+w@mail.gmail.com> (raw)
Hello,
I've noticed a potential issue with USB4NET when used in conjunction
with Linux bridging. I'm uncertain if it's a bug or a configuration
oversight on my part.
In essence, when the device at the other end of Thunderbolt sends
packets using the TSO mechanism (default behavior in macOS), the Linux
thunderbolt0 interface correctly receives this large packet. However,
the packet isn't properly forwarded to another device via bridging.
Detailed Description:
The test environment consists of three systems:
A: Mac Mini (M2): macOS Sonoma 14.0 RC
B: Proxmox VE 8.0. Kernel release: 6.2.16-3-pve, acting as the Host system.
C: Debian. A Guest system running within B.
System A and B are connected via USB4, while System C is a virtual
machine within B. On B, thunderbolt0 and tap102i0 are bridged to
establish a connection between A and C.
During an iperf3 speed test between A and B, I've achieved
bi-directional speeds of around 18Gbps. Between B and C, the speeds
are 100Gbps+ at their peak, with a minimum of 28Gbps.
However, when performing an iperf3 speed test between A and C, the
direction from C to A shows about 18Gbps, but from A to C, the speed
drops to just tens of Kbps, essentially making it unusable.
If tested using UDP, both directions achieve roughly 5Gbps. (I suspect
some buffer issue in macOS limiting the speed).
After various tests and investigations, I found that by setting
macOS's net.inet.tcp.tso to 0 (disabling TSO), speeds from A to C
improved to around 10Gbps.
Packet capture via tcpdump revealed that macOS writes large packets
(over 10000B) to Thunderbolt Networking using TSO. These packets are
correctly captured on thunderbolt0, but are missing from tap102i0,
resulting in significant packet loss.
Since ethtool doesn't support the thunderbolt0 device, further testing
has been hindered.
I'm unsure if this is a bug, or if it could be resolved via
configuration. If more information is needed, I am more than willing
to assist further with tests.
Thank you.
Warm regards,
Yachen Liu
next reply other threads:[~2023-09-14 14:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-14 14:02 Yachen Liu [this message]
2023-09-14 15:51 ` [Bug][USB4NET] Potential Bug with USB4NET and Linux Bridging Mika Westerberg
2023-09-14 16:07 ` Yachen Liu
2023-09-15 12:53 ` Andrew Lunn
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=CAPsLH6aHJGG7kAaZ7hdyKoSor4Ws2Fwujjjxog6E_bQrY1fA+w@mail.gmail.com \
--to=blankwonder@gmail.com \
--cc=YehezkelShB@gmail.com \
--cc=michael.jamet@intel.com \
--cc=mika.westerberg@linux.intel.com \
--cc=netdev@vger.kernel.org \
/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.