Try to improve the documentation on registered buffers

It seems to have caused confusion regarding the relation between io_uring
and the fellow memory cache, which exists only to the extent that io_uring
manages IO in and out of it.
parent 33e9724c
...@@ -791,7 +791,9 @@ FELLOW KNOWN ISSUES ...@@ -791,7 +791,9 @@ FELLOW KNOWN ISSUES
* On Linux with ``io_uring``, by default, `fellow` registers all of * On Linux with ``io_uring``, by default, `fellow` registers all of
the memory cache as buffers using the memory cache as buffers using
:ref:`io_uring_register_buffers(3)` to achieve optimal performance :ref:`io_uring_register_buffers(3)` to achieve optimal performance
at runtime, if supported by the system. at runtime, if supported by the system. Where supported, this
enables *zero-copy* IO, where the hardware performs DMA directly
into the `fellow` memory cache.
Buffer registrations happen in multiple threads in parallel, one for Buffer registrations happen in multiple threads in parallel, one for
each io ring. each io ring.
...@@ -811,6 +813,9 @@ FELLOW KNOWN ISSUES ...@@ -811,6 +813,9 @@ FELLOW KNOWN ISSUES
registration is forced to be done as serial, syncronous registration registration is forced to be done as serial, syncronous registration
operations. operations.
Note that even with registered buffers, ``io_uring`` has nothing to
do with how the `fellow` memory cache and LRU on it work.
* If initialization takes longer than the :ref:`varnishd(1)` * If initialization takes longer than the :ref:`varnishd(1)`
``cli_timeout``, it might not come up properly in that it does not ``cli_timeout``, it might not come up properly in that it does not
accept connections after finishing storage initialization. To avoid accept connections after finishing storage initialization. To avoid
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment