Zero-copy networking

Posted Jul 4, 2017 8:36 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
In reply to: Zero-copy networking by cladisch
Parent article: Zero-copy networking

That's pretty much how userspace network stacks work these days. To replicate it, a client will have to set up some kind of a lockless ring buffer and a way for the kernel to wake up the the client. But the API won't look like sockets anymore.

Zero-copy networking

Posted Jul 6, 2017 1:10 UTC (Thu) by vomlehn (guest, #45588) [Link] (1 responses)

It's still possible to put a sockets API on such a ring buffer based interface but any approach I know of will then require for receive...a copy out of the ring buffer. I think that, ultimately, we need recognize that we need a new set of APIs for zero-copy operations. You use those if you want maximum performance, otherwise you use the familiar sockets interface, which is layered on the zero copy APIs.

By "new", I just mean new for Linux. There are candidate APIs out there that should be considered. The HPC guys are kind of nuts about shipping data, so they have at least one possibility, though I haven't used them. I've heard comments implying that their environment doesn't mandate the level of security a more general Linux deployment might need but this is, again, hearsay.

Zero-copy networking

Posted Apr 25, 2018 14:48 UTC (Wed) by mikemol (guest, #83507) [Link]

I think zero-copy should be possible with a sockets API.

You still use the ring buffer, but you only drain the buffer when there are read() calls on the socket. Send ACKs only for the packets whose data have been consumed by read() calls.

This further allows you to combat bufferbloat at the application layer.