mirror of
http://git.haproxy.org/git/haproxy.git/
synced 2024-12-19 18:28:33 +00:00
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.
This commit is contained in:
parent
d2a2014f15
commit
792a645ec2
@ -3046,8 +3046,16 @@ static size_t qmux_strm_done_ff(struct stconn *sc)
|
||||
qcs->flags |= QC_SF_FIN_STREAM;
|
||||
}
|
||||
|
||||
if (!(qcs->flags & QC_SF_FIN_STREAM) && !sd->iobuf.data)
|
||||
if (!(qcs->flags & QC_SF_FIN_STREAM) && !sd->iobuf.data) {
|
||||
TRACE_STATE("no data sent", QMUX_EV_STRM_SEND, qcs->qcc->conn, qcs);
|
||||
|
||||
/* There is nothing to forward and the SD is blocked. Try to
|
||||
* release the TXBUF to retry.
|
||||
*/
|
||||
if ((qcs->sd->iobuf.flags & IOBUF_FL_FF_BLOCKED) && !qcc_release_stream_txbuf(qcs))
|
||||
qcs->sd->iobuf.flags &= ~IOBUF_FL_FF_BLOCKED;
|
||||
goto end;
|
||||
}
|
||||
|
||||
data += sd->iobuf.offset;
|
||||
total = qcs->qcc->app_ops->done_ff(qcs);
|
||||
|
Loading…
Reference in New Issue
Block a user