Hacker Newsnew | past | comments | ask | show | jobs | submitlogin



https://mazzo.li/posts/fast-pipes.html#splicing :

> In general when we write to a socket, or a file, or in our case a pipe, we’re first writing to a buffer somewhere in the kernel, and then let the kernel do its work. In the case of pipes, the pipe is a series of buffers in the kernel. All this copying is undesirable if we’re in the business of performance.

> Luckily, Linux includes system calls to speed things up when we want to move data to and from pipes, without copying. Specifically:

> - splice moves data from a pipe to a file descriptor, and vice-versa.

> - vmsplice moves data from user memory into a pipe.

> Crucially, both operations work without copying anything.

But then to scale to more than one node, everything has to be copied from the pipe buffer to the network socket buffer; unless splice()'ing from a pipe to a socket is Zero-copy like sendfile() (which doesn't work with pipes IIRC).

"SOCKMAP - TCP splicing of the future" (2019) https://blog.cloudflare.com/sockmap-tcp-splicing-of-the-futu...


sendfile is implemented with splice, but the scenario in which splice is actually zero-copy is not well defined (man pages just say "it's generally avoided"), so you'd have to dig into your kernel source to know for sure. That being said, chances are the cost of copying the data would be far outpaced by the cost of serializing over the network anyways, so you would want to architect your application in a way that you're sending as little data over the network as possible if performance is of maximum concern.


I haven't checked, but by the end of the day, I doubt eBPF is much slower than select() on a pipe()?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: