On Wed, 18 Mar 2026 10:19:38 +0100
Laurent Vivier
This series prepares the vhost-user path for multi-buffer support, where a single virtqueue element can use more than one iovec entry.
Currently, iovec arrays are tightly coupled to virtqueue elements: callers must pre-initialize each element's in_sg/out_sg pointers before calling vu_queue_pop(), and each element is assumed to own exactly one iovec slot. This makes it impossible for a single element to span multiple iovec entries, which is needed for UDP multi-buffer reception.
The series decouples iovec storage from elements in three patches:
- Patch 1 passes iovec arrays as separate parameters to vu_queue_pop() and vu_queue_map_desc(), so the caller controls where descriptors are mapped rather than reading them from pre-initialized element fields.
- Patch 2 passes the actual remaining out_sg capacity to vu_queue_pop() in vu_handle_tx() instead of a fixed per-element constant, enabling dynamic iovec allocation.
- Patch 3 moves iovec pool management into vu_collect(), which now accepts the iovec array and tracks consumed entries across elements with a running counter. This removes vu_set_element() and vu_init_elem() entirely. Callers that still assume one iovec per element assert this invariant explicitly until they are updated for multi-buffer.
The follow-up udp-iov_vu series builds on this to implement actual multi-buffer support in the UDP vhost-user path.
v3: - rebase and add David's R-b - fix coding style (if) - rename in_num to in_total
Applied. I took the liberty to add David's Reviewed-by: back on 3/3 as the only change in 3/3 v3 compared to v2 was actually something he suggested. -- Stefano