Re: [PATCH 0/3] vmsplice: make vmsplice a trivial wrapper for preadv2/pwritev2
Willy Tarreau <[email protected]>
| Newsgroups | org.kernel.vger.linux-api,dev.linux.lists.patches,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.netdev,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
On Thu, Jun 04, 2026 at 06:15:41PM +0200, Willy Tarreau wrote: > On Thu, Jun 04, 2026 at 08:58:33AM -0700, Linus Torvalds wrote: > > On Thu, 4 Jun 2026 at 08:53, Willy Tarreau <[email protected]> wrote: > > > > > > > It looks like you're actually doing exactly the thing that I thought > > > > was crazy and wouldn't even work reliably: you change the > > > > common_response[] contents dynamically *after* the vmsplice, and > > > > depend on the fact that changing it in user space changes the buffer > > > > in the pipe too. > > > > > > No no, it's definitely not doing that (or it's a bug, but it's not > > > supposed to happen). I'm perfectly aware that one must definitely not > > > do that, and it's a guarantee the user of vmsplice() must provide. > > > > Whew, good. > > > > In that case, can you just try the vmsplice patch series (Christian > > already found a bug, but I don't think it will necessarily matter in > > practice - famous last words) and that test patch of mine, and see if > > it all (a) works for you and (b) if you have any numbers for > > performance that would be *great*. > > Yes I wanted to do that and noted it on my todo list yesterday when > noticing the ongoing discussion. Just been super busy with yesterday's > by-yearly release ;-) But at least I wanted to share quick feedback in > this thread about existing uses. OK so I could run the test this afternoon, with: - ddd664bbff63 Merge tag 'net-7.1-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net (v7.1-rc6-178) - the same with Christian's vfs-7.2.vmsplice branch merged into it ( 8d86fcfc2857 include/linux/splice.h: trivial fix: declerations -> declarations) Both show 71-72 Gbps of TLS traffic per core on my test utility (I stopped at 3 cores since having only 2x100G at the moment), so for this use case I'm not impacted by the change. I noted that I will have to reconsider other options for the cache (send(MSG_ZEROCOPY) probably) but in my case since the code doesn't exist yet it's not per-se a userland breakage, but a change of plans. I just hope I'll find my way through the alternate solution. FWIW for Christian's branch: Tested-by: Willy Tarreau <[email protected]> Willy