The stream can process completions directly from read and write calls. That changes how a program waits for data, as well as the CPU time it may spend doing so.
The code is now in the release candidate
The USB4STREAM commit adds busy_poll to each stream’s ConfigFS attributes. The implementation is present in Linux 7.3-rc2 stream.c. It advances transfer-ring completions from read and write paths instead of relying on their interrupt-driven completion path.
With busy polling active, the poll callback returns an error readiness mask. A blocking read with no available data keeps polling, checking signals and allowing rescheduling. A nonblocking read can return EAGAIN. The old assertion that an entire core spins permanently whenever a stream exists was too broad.
Configure before opening the stream
The busy_poll store function checks whether the stream has users. If so, it returns EBUSY rather than changing the mode underneath open users. This is an important difference from a live performance knob that an administrator can flip at any time.
Our diagram compares three cases with an empty receive queue: ordinary blocking waiting, a blocking read in busy mode, and a nonblocking read in busy mode. It shows control flow, not measured delay. Creating a stream without an active polling call is not the same as running a dedicated spinning reader.
Measure latency together with CPU time
For an evaluation, keep packet size, offered load, cable, hardware and process placement fixed. Include a quiet period and bursts, not only saturation. Record latency distribution and CPU time over the same interval. A lower median accompanied by worse tail latency or unacceptable CPU use can change the deployment decision.
An application using readiness-based multiplexing must account for the changed poll behavior. Replacing that wait with repeated reads may alter cancellation, fairness between streams and shutdown. The kernel code still runs; busy polling is not synonymous with kernel bypass or zero scheduling overhead.
We have not timed a USB4 link for this article. The code supports a narrower conclusion: the new mode offers an alternative completion path with explicit waiting semantics. Whether it improves a particular application requires measurements of that application, not a general promise inferred from the word “polling.”
September 8: verify 7.3-rc2 code, correct permanent-core claims, and document polling-call behavior and EBUSY when changing an opened stream.