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

[Mika Westerberg <mika.westerberg@linux.intel.com>]

Hi,

On Mon, Nov 02, 2026 at 04:39:15PM +0100, Alan Borzeszkowski wrote:
> 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.

That sounds like a good reason to include it IMHO. Also I like the
simplicity - no need to run a separate descriptor feeding process :)

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

If Dominique is okay with this, I suggest to send v2 with a MAINTAINERS
update as well.