Comment by BeeOnRope
How does bytes crate, or anyone else, offer zero copy receive from kernel (as opposed to kernel bypass) sockets?
As far as I know that is not possible: there's always a copy.
How does bytes crate, or anyone else, offer zero copy receive from kernel (as opposed to kernel bypass) sockets?
As far as I know that is not possible: there's always a copy.
Thanks, you mention explicitly kernel networking right below about the send path:
> before flinging them at the kernel as [vectors of] large, contiguous DMA requests, without having to stop to allocate
So I had assumed you were taking about kernel networking elsewhere as well.
BTW, on the kernel send path, there is again a copy, contiguous or not, regardless of what API you use.
When using kernel networking I don't think contiguity matters as you suggest, as there is always a copy. Furthermore "contiguous" in userspace doesn't correspond to contiguous in physical address space so in any case the hardware is just often going to see a userspace buffer as a series of discontiguous pages anyway: that's what happens with direct IO disk writes, which _are_ zero copy (huge pages helps).
For network receive, I was assuming kernel-bypass sockets, not kernel sockets.
`bytes` can give you "ring-buffer-like" one-copy kernel-socket receive by e.g. using the Buf as the target for scheduling io_uring read/recv into.
Also, RDMA is technically networking! (Though I think all the Rust RDMA libraries already provide ADTs that work like Buf/MutBuf, rather than just saying "here's some network-shared memory, build your own ADT on top.")