haproxy/doc/internals
Willy Tarreau 72d0dcda8e MINOR: dynbuf: pass a criticality argument to b_alloc()
The goal is to indicate how critical the allocation is, between the
least one (growing an existing buffer ring) and the topmost one (boot
time allocation for the life of the process).

The 3 tcp-based muxes (h1, h2, fcgi) use a common allocation function
to try to allocate otherwise subscribe. There's currently no distinction
of direction nor part that tries to allocate, and this should be revisited
to improve this situation, particularly when we consider that mux-h2 can
reduce its Tx allocations if needed.

For now, 4 main levels are planned, to translate how the data travels
inside haproxy from a producer to a consumer:
  - MUX_RX:   buffer used to receive data from the OS
  - SE_RX:    buffer used to place a transformation of the RX data for
              a mux, or to produce a response for an applet
  - CHANNEL:  the channel buffer for sync recv
  - MUX_TX:   buffer used to transfer data from the channel to the outside,
              generally a mux but there can be a few specificities (e.g.
              http client's response buffer passed to the application,
              which also gets a transformation of the channel data).

The other levels are a bit different in that they don't strictly need to
allocate for the first two ones, or they're permanent for the last one
(used by compression).
2024-05-10 17:18:13 +02:00
..
api MINOR: dynbuf: pass a criticality argument to b_alloc() 2024-05-10 17:18:13 +02:00
acl.txt
body-parsing.txt
connect-status.txt
connection-header.txt
connection-scale.txt
fd-migration.txt
hashing.txt
list.fig
list.png
listener-states.fig
listener-states.png
lua_socket.fig
lua_socket.pdf
muxes.fig
muxes.pdf
muxes.png
muxes.svg
notes-layers.txt
notes-poll-connect.txt
notes-pollhup.txt
notes-polling.txt
pattern.dia
pattern.pdf
polling-states.fig
sched.fig
sched.pdf
sched.png
sched.svg
ssl_cert.dia
stats-v2.txt
stconn-close.txt
stream-sock-states.fig