-
|
"Copy avoidance is not a free lunch. As implemented, with page pinning, it replaces per byte copy cost with page accounting and completion notification overhead. As a result, MSG_ZEROCOPY is generally only effective at writes over around 10 KB." |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
That's also applies to
The math is different with io_uring, with UDP and all features I had parity with non zc at around 2K. The main performance pain there is notifications, but since my last testing I added some smartness to the CQE waiting side, so with good batching it might go under 2K. In any case, I'd recommend to always experiment and see what works in your setup. |
Beta Was this translation helpful? Give feedback.
-
|
where is the best source for knowing if a new kernel version has succeeded in lowering the bar? I am looking for new ways to shave off any possible nanoseconds to my WebSockets over TLS writes... I have come here to find an answer to the same question than the OP.... I am sending out occasionally few 6KB messages but most of the time they are 500 bytes or less... This is these small 500 bytes messages that are the most latency sensitive... I do not care much about the notification overhead... The only thing that matters to me is how fast the TCP segment will go out on the wire when I need it to be fast |
Beta Was this translation helpful? Give feedback.
That's also applies to
SEND[MSG]_ZCas well. There is no page pinning when used with registered buffers (seeIORING_RECVSEND_FIXED_BUF, not yet available for themsgversion), but additional overhead on notifications is still there.The math is different with io_uring, with UDP and all features I had parity with non zc at around 2K. The main performance pain there is notifications, but since my last testing I added some smartness to the CQE waiting side, so with good batching it might go under 2K. In any case, I'd recommend to always experiment and see what works in your setup.