Re: [PATCH 0/3] net/9p: Add 9P transport over USB4STREAM

[Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com>]

Hi,

On Thu, 2026-10-29 at 11:45 +0900, Dominique Martinet wrote:
> Alan Borzeszkowski wrote on Thu, Sep 24, 2026 at 06:23:30PM +0200:
> > This series adds trans=thunderbolt, a 9P transport over the
> > Thunderbolt/USB4 DMA tunnels exposed by the tbstream character
> > devices
> > (USB4STREAM). It's designed for simple host-to-host file sharing
> > over
> > single Thunderbolt/USB4 cable.
> > 
> > Today the only practical way to use 9P over a USB4 link is trans=fd
> > which, due to its design, cannot fully utilize USB4STREAM
> > capabilities.
> > Thunderbolt transport offers a simpler mount (no fd redirection
> > required),
> > busy-poll support and substantial throughput increase compared to
> > FD
> > transport.
> > 
> > User may mount 9P export with following command:
> > 
> > mount -t 9p -o trans=thunderbolt,aname=<exported_remote>
> > /dev/tbstreamX /mnt
> > 
> > Thunderbolt transport achieves a median 1.21x more throughput
> > compared
> > to FD transport under same conditions, and the advantage grows with
> > concurrency: 1.03-1.09x at 1-2 threads, 1.14-1.27x at 4, and 1.34-
> > 2.28x
> > at 8-16.
> > 
> > As an example, 4K random reads, 4 worker threads. FD transport
> > achieves
> > ~53k IOPS, Thunderbolt transport ~66k (+24.7%). 4K random writes
> > follow:
> > FD ~28k IOPS, Thunderbolt ~33k (+19.4%).
> 
> Thanks for the patches
> 
> We've kept adding new transports for 9p lately but maintenance is
> becoming a burden so let me push back a bit: is the increased
> performance really worth it over trans=fd ?

From the data I've collected, yes. trans=thunderbolt is at worst on par
with trans=fd and with increasing amount of threads, trans=fd lags
behind.

Thunderbolt transport also offers busy-poll support, which boosts
performance significantly at low thread counts. It cannot be used by
trans=fd due to its design around polling.

And regarding maintenance, this transport is simple and much smaller
than existing ones.

> 
> If this could be used to bringup a system with a root filesystem like
> it
> was done for trans=usbg I'd see the point, but otherwise the simpler
> usage could be addressed with a simple mount.9p helper, and at this
> point I'd consider usb4stream to be used for perhaps one-shot copy
> and
> not care too much about 4k random IOs (so less affected by latency
> if msize is large enough, and for a one-shot backup it doesn't matter
> too much if it takes 6 instead of 5 minutes)

In case of one-shot backup, I think my drag&drop scenario from cover-
letter fits it well. Assuming single thread copy, both transports
achieve similar results, but with busy-poll enabled, trans=thunderbolt
cuts about 1/3rd of copy time:
Copy from 9P client to a server, using trans=fd, takes 22m29s while
trans=thunderbolt + busy-poll takes 14m50s (~1.5x faster).
Reverse direction, same improvement: reducing copy time from 41m07s to
26m56s. All done on default msize.

> 
> If you can convince me this is worth it and can take care of the
> transport for the forseable future I'm not dead set to refuse this,
> but
> I can't say I'm convinced right now, especially as I can't even test
> this (I don't own two computers with working usb-c...)

I would be happy to maintain Thunderbolt transport.

> 
> Thanks,