[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5d2f7260-819f-4197-b3a6-a7146cb71f66@lunn.ch>
Date: Fri, 15 Sep 2023 14:53:46 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Yachen Liu <blankwonder@...il.com>
Cc: netdev@...r.kernel.org, michael.jamet@...el.com,
mika.westerberg@...ux.intel.com, YehezkelShB@...il.com
Subject: Re: [Bug][USB4NET] Potential Bug with USB4NET and Linux Bridging
On Thu, Sep 14, 2023 at 10:02:24PM +0800, Yachen Liu wrote:
> 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.
Maybe three is a concept mix up here. TSO is TCP Segmentation Offload.
The network stack gives the NIC a large buffer and a template
Ethernet, IP and TCP header. The NIC is then supposed to send MTU
sized frames on the wire, performing segmentation and appending real
headers to each Frame.
We also have Jumbo packets. These are a single frames which are bigger
than he standard 1500 MTU.
You can also combine these. So the stack could for example pass a 64K
buffer to the NIC for TSO, and the MTU could be 8K. So you would
expect to see 8 frames on the wire.
When running tcpdump, what do you actually see? Is TSO actually
happening? Are the frames the size of the MTU or less?
Andrew
Powered by blists - more mailing lists