On Fri, Mar 20, 2026 at 09:58:17PM +0100, Stefano Brivio wrote: > On Wed, 18 Mar 2026 10:19:38 +0100 > Laurent Vivier 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