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

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2242 bytes --]

On Fri, Mar 20, 2026 at 09:58:17PM +0100, Stefano Brivio wrote:
> 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.

Oh, sorry, I thought I'd already R-b'ed all of v3.

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]