From: Willy Tarreau Date: Thu, 3 Oct 2024 14:09:18 +0000 (+0200) Subject: MAJOR: mux-h2: permit a stream to allocate as many buffers as desired X-Git-Tag: v3.1-dev10~80 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=3816c38;p=thirdparty%2Fhaproxy.git MAJOR: mux-h2: permit a stream to allocate as many buffers as desired Now we don't enforce allocation limits in h2s_get_rxbuf(), since there is no benefit in not processing pending data, it would still cause HoL for no saving. The only reason for not allocating is if there are no buffers available for the connection. In theory this should not change anything except that it excerts code paths that support reallocating multiple buffers, which could possibly uncover a sleeping bug. This is why it's placed in a separate commit. And one observation worth noting is that it almost cut in half the number of iocb wakeups: for 1000 1MB transfers over 100 concurrent streams of a single connection, we used to observe 208k wakeups (110 from restart_reading, 80 from snd_buf, 11 from done_ff), and now we're observing 128k (113 from restart_reading, 2.4 from snd_buf, 6.9k from done_ff), which seems to indicate that pretty often the demuxing was blocked on a buffer full due to the default advertised window of 64k. --- diff --git a/src/mux_h2.c b/src/mux_h2.c index ef62b1b955..3c1d7051d3 100644 --- a/src/mux_h2.c +++ b/src/mux_h2.c @@ -745,10 +745,6 @@ static inline uint h2s_get_rxbuf(struct h2s *h2s) { uint slot; - /* FIXME: for now each stream is granted exactly one buffer */ - if (h2s->rx_count) - return 0; - slot = bl_get(h2s->h2c->shared_rx_bufs, h2s->rx_tail); if (!slot) return 0;