]> git.ipfire.org Git - thirdparty/haproxy.git/commit
MEDIUM/OPTIM: mux-quic: do not rebuild frms list on every send
authorAmaury Denoyelle <adenoyelle@haproxy.com>
Thu, 12 Dec 2024 11:03:37 +0000 (12:03 +0100)
committerAmaury Denoyelle <adenoyelle@haproxy.com>
Wed, 18 Dec 2024 08:49:02 +0000 (09:49 +0100)
commit14710b5e6bf76834343d58db22e00b72590b16fe
treee87ec3015b208d89f7fe0b470e3670b4bfc8112c
parent9ecc1a8e578c67e8653ba7d1e9c5441f5ad2eca8
MEDIUM/OPTIM: mux-quic: do not rebuild frms list on every send

A newly introduced frames list member has been defined into QCC instance
with pacing implementation. This allowed to preserve STREAM frames built
between different emission scheduled by pacing, without having to
regenerate it if no new QCS data is available.

Generalize this principle outside of pacing scheduling. Now, the frames
list will be reused accross several qcc_io_send() usage. Frames list is
only cleared when necessary. This will force its refreshing in the next
qcc_io_send() via qcc_build_frms_list().

Frames list refreshing is performed in the following cases :
* on successful transfer from stream snd_buf / done_ff / shut
* on stream reset or read abort
* on max_data/max_stream_data reception with window increase

Note that the two first cases are in fact covered directly due to
qcc_send_stream() usage when QCS is (re)inserted into the send_list.

The main objective of this patch will be to remove QUIC MUX pacing
specific code path. It could also provide better performance as emission
of large frames may often be rescheduled due to transport layer, either
on congestion or full socket buffer. When QUIC MUX is rescheduled, no
new data is available and frames list can be reuse as-is, avoiding an
unecessary loop over send_list.

This should be backported up to 3.1.
src/mux_quic.c