[Question] Difference between SEND_ZC and provided buffers #1445
Replies: 3 comments 13 replies
-
|
SEND_ZC is to avoid copying memory into the kernel just for sending purposes. It maps and pins the userspace buffer and sends than, posting a 2nd notification whenever the data has been acked and is safe to reuse. Registered buffers pre-map/pin a userspace buffer. So no, they do not do the same thing at all, but registering a buffer saves a pin/map and unpin/unmap for each SEND_ZC. That operation is something that both SEND_ZC and O_DIRECT read/write on a file needs to do, pre-registrering the buffers does that once rather than per operation. |
Beta Was this translation helpful? Give feedback.
-
|
Moved this to a discussion, as it's not an issue. |
Beta Was this translation helpful? Give feedback.
-
|
@nikneym, pretty much as folks already mentioned, As for what's faster, normal sends can be faster than send zc depending on the payload size and other circumstances. Last time I benchmarked it, the parity for TCP was somewhere around 3K per send [1]. I'd recommend to try it for yourself and compare. And if you're using send zc, then also try to enable registered buffers, there are no (kernel) downsides in having them. [1] |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi, I couldn't wrap my mind around this specific situation, please correct me if I'm mistaken. SEND_ZC tries to skip internal buffers and puts the buffer directly to the wire if possible. Whereas the goal of registered I/O is to share the buffer between kernel and userspace to get rid of copy overhead.
Essentially these two seem to do the same thing, which is reducing copies. One extra cost of SEND_ZC could be the additional CQE it posts but other than that, I couldn't find a difference. Which one of them should be preferred over the other in what scenarios?
Beta Was this translation helpful? Give feedback.
All reactions