Re: [PATCH v3 0/3] Decouple iovec management from virtqueue elements

[Stefano Brivio <sbrivio@redhat.com>]

On Wed, 18 Mar 2026 10:19:38 +0100
Laurent Vivier <lvivier@redhat.com> wrote:

> 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