Tuesday, May 26th 2026
New Intel USB4Stream Driver and Protocol Enables Low-Latency Device-to-Device File Sharing in Linux Kernel 7.2
A new Linux driver developed by Intel maintainer, Mika Westerberg, has been revealed to be merging in the Linux kernel version 7.2, which is slated to launch in June 2026. The new driver will enable users to more easily share files over USB4 while bypassing the network driver. The developer pitches the new protocol as a way to easily back up, transfer, and access files across two or more connected systems, or even share hardware, like a webcam or input peripherals. For now, the protocol requires some setup, currently requiring users to set up devices using the ConfigFS interface, and the developer details a number of examples and commands to configure them. More importantly, because the stream is controlled by the receiving side, it seems as though after a little setup, the protocol could be used by app developers to create apps with similar functionality to LocalSend without the need for a network connection. The upstream request reads:
Source:
Linux Kernel Archives
Introduce USB4STREAM protocol and Linux implementation. This allows two (or more) hosts to transfer data directly over Thunderbolt/USB4 cable through a character device without need to go through the network stack.
Any application that supports read(2) and write(2) in some form should be able to use the device without changes. The data is sent out to the other side over a tunnel inside Thunderbolt/USB4 fabric. The character device is called /dev/tbstreamX where X is the minor number starting from 0.
13 Comments on New Intel USB4Stream Driver and Protocol Enables Low-Latency Device-to-Device File Sharing in Linux Kernel 7.2
For some reason it reminds me of the time I set up a direct serial link between two computers to play a two-player game of Stars!
There really isn't anything file sharing specific to this. The "real use-case" in the patch to justfy this feature goes on about using this raw data link to transfer files. That's a lot if 90s era fiddling about to move files over a data link. Is networking really such a boogie man you can't put it in your initramfs? Heck, even UEFI has a network stack. Why not just plug a flash drive into that USB port to do your backup? Feels very contrived.
Cool as an 80Gb serial port would be (Woot! My 3D Printer will never stall again.), file sharing this is not.
We don't need fast or large data transfers for the things I do and we use flash drives a lot to transfer files around but they often fail (and are themselves a security nightmare) so having a direct connection could be handy. You are right in that it would have to be easy to use though.
It has two Thunderbolt 4 ports, but the Thunderbolt networking wasn't really what I'd entirely reliable, nor did it perform better than 10 Gbps Ethernet in all tests.
Assuming this is more reliable, it might be a good addition for backing up a laptop.
USB is more annoying and has that whole Host/Gadget distinction which limits its usability (but also makes it safer). Best you can do is use bulk streams on USB3.0, and this version already has UAS for data transfers. For 2.0 it can be used if the controller supports it afaik, OW you're stuck with 2.0's slow BOT transfers.
Maybe the usual, new hardware is barely supported. The usual delay was around 3-4 years to see processor features adopted.
With the x800 series its even mandatory to have said controller.
That does DMA, already has polling and is low latency: 7.4 µs for a 8 KB write.
I'm looking for really low-latency PC-to-PC communication, particularly for local/clustered AI workloads, rather than just faster file transfers.
You/I want local AI... We just don't all know it yet.
The thunderbolt-ibverbs work from Hellas really caught my attention for it's low latency..
They report roughly 7 µs one-way latency for a 64-byte RDMA write over Thunderbolt. For comparison, their figures are around 28 µs for RXE over 2.5GbE and 65 µs for RXE over thunderbolt-net.
USB4STREAM itself is obviously a different interface, and I haven't seen an equivalent latency benchmark for it yet, hich is precisely why I'm interested.
It makes me wonder whether we're approaching an "Optane moment" for PC-to-PC I/O:
Once the underlying link is fast enough, the software stack and protocol overhead start becoming a major part of the latency.
Thunderbolt already has some of the relevant ingredients underneath:
PCIe tunnelling, NHI/DMA machinery, etc.
The really interesting question to me is:
How close can we get to PCIe-like latency between independent PCs without actually putting them on the same PCIe fabric?
For local/clustered AI, that could be considerably more interesting than simply treating USB4 as "faster networking".
Low-latency computer-to-computer interconnects is where its at IMHO.