On Fri, 2 Oct 2026 18:39:25 +0200
"Bernhard M. Wiedemann"
without this patch, sending buffers of certain sizes caused a delay of 200ms because tcp_splice_forward() passes SPLICE_F_MORE to the writer when a read filled at least 90% of the pipe.
This is easy to hit when pipes are small: once a user exceeds fs.pipe-user-pages-soft (64 MiB by default, which a few long-running pasta instances with large pipes reach on their own), tcp_set_pipe_size() settles on the 8 KiB minimum, and every message whose length is 7372 to 8192 bytes (90% of the pipe and more) past a multiple of 8 KiB stalls.
This change leaves bulk throughput unchanged.
Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Bernhard M. Wiedemann
---
Applied, thanks, sorry for the delay, and welcome to the git log!
Notes: The change was slightly tested and benchmarked. Results look decent.
I also played a bit with it and the scripts you supplied in different setups, and couldn't find any relevant issue either. It might be worth having them (with license, usage and all) under, say, doc/performance/ or something like that. I don't have a big preference either way, though, because after all we already have the same tests using iperf3 and tcp_rr.
Not sure if we actually need the flow_trace for error handling there.
I think yes, that's actually useful should it ever happen. -- Stefano