Re:QUIC is now RFC 9000
by MichaelMoser123 on Friday May 28, 2021 @04:21AM
(#27312976)
i think the intent is that normally you would do a lot of syscalls in order to do networking; with QUICK you would currently be forced to do do zero-copy networking and pass the frames to the kernal via pf-ring; things don't become simpler, as the network layers will have to be handled by a user mode library, however they would potentially be much faster.
[ Parent
| on HN ]
> forced
?? why shouldn't quick be able to use a udp socket?
Re:QUIC is now RFC 9000
by MichaelMoser123 on Friday May 28, 2021 @05:30AM
(#27313321)
you can do that, if you can to accept the overhead of a system call per outgoing/incoming frame.
or use sendmmsg(2) and recvmmsg(2)
Re:QUIC is now RFC 9000
by Matthias247 on Friday May 28, 2021 @02:12PM
(#27318676)
Those work and will reduce the system call overhead. But testing showed that it isn't actually the main culprit (e.g. you might gain 5% efficiency by going for it).
A far bigger bottleneck with the kernel stack is that e.g. the route lookup, iptable rules and similar things will be evaluated per packet - which is taking up most of the time. That will happen independent of you deliver one packet per system call or multiple of those.
UDP Generic segmentation offload (GSO - https://lwn.net/Articles/752184/) reduces that overhead by amortizing all in-kernel and driver operations over batches of datagrams. It makes a far bigger difference in efficiency than purely reducing syscalls (e.g. to +100% efficiency - but it will all depend on the other work the application and QUIC stack does and what drivers support).