]> git.ipfire.org Git - thirdparty/haproxy.git/commit
BUG/MEDIUM: mux-quic: Unblock zero-copy forwarding if the txbuf can be released
authorChristopher Faulet <cfaulet@haproxy.com>
Tue, 4 Jun 2024 10:04:48 +0000 (12:04 +0200)
committerChristopher Faulet <cfaulet@haproxy.com>
Tue, 4 Jun 2024 12:23:40 +0000 (14:23 +0200)
commit792a645ec21126c74c33820d1e0de63ee98aa810
tree50c23167d87af80a78c7fe8e4bd71210f15f3e93
parentd2a2014f152c09ff4f28c03a4ff6c5aae000ad5d
BUG/MEDIUM: mux-quic: Unblock zero-copy forwarding if the txbuf can be released

In done_fastfwd() callback function, if nothing was forwarding while the SD
is blocked, it means there is not enough space in the buffer to proceed. It
may be because there are data to be sent. But it may also be data already
sent waiting for an ack. In this case, no data to be sent by the mux. So the
quic stream is not woken up when data are finally removed from the
buffer. The data forwarding can thus be stuck. This happens when the stats
page is requested in QUIC/H3. Only applets are affected by this issue and
only with the QUIC multiplexer because it is the only mux with already sent
data in the TX buf.

To fix the issue, the idea is to release the txbuf if possible and then
unblock the SD to perform a new zero-copy data forwarding attempt. Doing so,
and thanks to the previous patch ("MEDIUM: applet: Be able to unblock
zero-copy data forwarding from done_fastfwd"), the applet will be woken up.

This patch should fix the issue #2584. It must be backported to 3.0.
src/mux_quic.c