You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since 5.0, Linux implements a new UDP socket option, UDP_GRO, 1 which allows batch reading of UDP datagrams with recvmsg/recvmmsg. It would be nice to support it in DNSdist.
Usecase
All UDP-based sockets (Do53 UDP, DoQ, DoH3) could in theory benefit from this option. We already support recvmmsg for Do53 UDP and I don't think it would be too hard to implement that for DoQ and DoH3 if we see a real improvement for Do53 UDP.
We would need to set the option on the socket via setsockopt, when available, make sure we have enough room in the cmsg control buffer for the additional uint16_t size field, and split the data received in our buffer according to this size (since the buffer can now hold more than one datagram).
The text was updated successfully, but these errors were encountered:
Short description
Since 5.0, Linux implements a new
UDP
socket option,UDP_GRO
, 1 which allows batch reading of UDP datagrams withrecvmsg
/recvmmsg
. It would be nice to support it in DNSdist.Usecase
All UDP-based sockets (Do53 UDP, DoQ, DoH3) could in theory benefit from this option. We already support
recvmmsg
for Do53 UDP and I don't think it would be too hard to implement that for DoQ and DoH3 if we see a real improvement for Do53 UDP.cURL reports 39% faster DoH3 downloads: curl/curl#14012
Description
We would need to set the option on the socket via
setsockopt
, when available, make sure we have enough room in the cmsg control buffer for the additionaluint16_t
size field, and split the data received in our buffer according to this size (since the buffer can now hold more than one datagram).The text was updated successfully, but these errors were encountered: