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)
committerChristopher Faulet <cfaulet@haproxy.com>
Mon, 6 Jan 2025 10:21:52 +0000 (11:21 +0100)
commit8a926ea3e47e2ae6a9eeebed9cf7cecc74b09e69
treec85cc371eafe3b169c49e1c64ec3654746e0f3ee
parent3a00193b242f41c7d3070d9b488f4ff28bed4722
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.

(cherry picked from commit 14710b5e6bf76834343d58db22e00b72590b16fe)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
src/mux_quic.c