On Wed, Oct 14, 2026 at 10:37:31PM +0900, Yeonggi Kim wrote: > Hi Amaury, > Thank you for the review. Here are my answers, with two questions > before I send a v2.
Thanks for the quick follow-up, > 1. OK for both: src will come before dst, and addr will be renamed to > dst. Good, > 2. OK, the new emission function will be introduced without the EINTR > loop, which will come in a separate patch at the end of the series. Perfect, > 3. The listener socket is already non-blocking, as fd_set_nonblock() is > called in sock_inet_bind_receiver(), including for inherited FDs, so > MSG_DONTWAIT does not change anything here. As for MSG_NOSIGNAL, send(2) > only mentions it for stream-oriented sockets, and haproxy ignores > SIGPIPE anyway (signal_register_fct(SIGPIPE, NULL, 0) in haproxy.c). So > I would rather drop both flags, which keeps the exact behavior of the > current sendto() calls, and add a comment stating that a datagram is > simply lost when the socket buffer is full, as there is no connection > to retry its emission later. Would that be fine with you? If you prefer > to keep MSG_DONTWAIT for consistency with qc_snd_buf(), I can do that > instead, with the same comment. Good catch regarding non-blocking FD. I also think it's better to remove both flags and add a comment to mention the potential packet drop, as this is already the current behavior. > 4. Your approach is clearer, so I will follow it, including the > quic_lstnr_sock_send() name. A first patch will make send_retry() and > send_version_negotiation() take the listener (send_stateless_reset() > already does), and quic_lstnr_sock_send() will take it as well and > check quic_lstnr_may_set_src() itself. Callers will then always pass > dgram->daddr as source, the same way they already pass dgram->saddr as > destination. The v2 would thus be: listener argument, > quic_lstnr_sock_send(), the three fixes, the regtest, and the EINTR > retry last. Great it sounds perfect, > There is also one behavior change to report. When a client targets an > IPv4 broadcast address (255.255.255.255 or a subnet broadcast), Linux > rejects it as an explicit source address and sendmsg() fails with > EINVAL. In connection socket mode, such a connection currently works, > even with Retry, because the connection socket is bound on the > broadcast address and the kernel then selects the source address > itself. With the series, Retry, VN and Stateless Reset are no longer > emitted to these clients. In listener socket mode, these connections > already fail without the series, as qc_snd_buf() hits the same EINVAL. > I do not think this matters in practice, but if you prefer, > quic_lstnr_sock_send() could retry once without source address on > EINVAL, so that emission never regresses. What do you think? I'm not sure about it as this could be regarded as a regression, even if I do not see any interest of using QUIC targetting a broadcast address currently. Maybe quic_lstnr_may_set_src() should also report false for the broadcast range ? I'll ask the opinions of Fred and Willy tomorrow on this particular point. Regards, -- Amaury Denoyelle
