From: Stefano Brivio <sbrivio@redhat.com>
To: Laurent Vivier <lvivier@redhat.com>
Cc: passt-dev@passt.top, Jon Maloy <jmaloy@redhat.com>,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [PATCH v4 00/10] vhost-user: Preparatory series for multiple iovec entries per virtqueue element
Date: Wed, 20 May 2026 02:52:09 +0200 (CEST) [thread overview]
Message-ID: <20260520025208.5f31e61e@elisabeth> (raw)
In-Reply-To: <20260513115218.1662850-1-lvivier@redhat.com>
On Wed, 13 May 2026 13:52:08 +0200
Laurent Vivier <lvivier@redhat.com> wrote:
> Currently, the vhost-user path assumes each virtqueue element contains
> exactly one iovec entry covering the entire frame. This assumption
> breaks as some virtio-net drivers (notably iPXE) provide descriptors where the
> vnet header and the frame payload are in separate buffers, resulting in
> two iovec entries per virtqueue element.
>
> This series refactors the vhost-user data path so that frame lengths,
> header sizes, and padding are tracked and passed explicitly rather than
> being derived from iovec sizes. This decoupling is a prerequisite for
> correctly handling padding of multi-buffer frames.
>
> The changes in this series can be split in 3 groups:
>
> - New iov helpers (patches 1-2):
>
> iov_memset() and iov_memcpy() operate across iovec boundaries.
> These are needed by the final patch to pad and copy frame data
> when a frame spans multiple iovec entries.
>
> - Structural refactoring (patches 3-5):
>
> Move vnethdr setup into vu_flush(), separate virtqueue management
> from socket I/O in the UDP path, and pass iov arrays explicitly
> instead of using file-scoped state. These changes make it possible
> to pass explicit frame lengths through the stack, which is required
> to pad frames independently of iovec layout.
>
> - Explicit length passing throughout the stack (patches 6-10):
>
> Thread explicit L4, L2, frame, and data lengths through checksum,
> pcap, vu_flush(), and tcp_fill_headers(), replacing lengths that
> were previously derived from iovec sizes. With lengths tracked
> explicitly, the final patch can centralise Ethernet frame padding
> into vu_collect() and a new vu_pad() helper that correctly pads
> frames spanning multiple iovec entries.
>
> v4:
> - rebase
> - iov_memcpy: use size_t for loop indices i and j
> - udp_vu: reorder elem[] declaration for inverted christmas tree style
> - pcap: wrap pcap_iov() declaration and definition to respect line length
> - write_remainder(): update length parameter description
> - Add Reviewed-by tags from Jon and David
Applied, sorry for the delay.
--
Stefano
next prev parent reply other threads:[~2026-05-20 0:52 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-13 11:52 Laurent Vivier
2026-05-13 11:52 ` [PATCH v4 01/10] iov: Introduce iov_memset() Laurent Vivier
2026-05-13 11:52 ` [PATCH v4 02/10] iov: Add iov_memcpy() to copy data between iovec arrays Laurent Vivier
2026-05-13 11:52 ` [PATCH v4 03/10] vu_common: Move vnethdr setup into vu_flush() Laurent Vivier
2026-05-13 11:52 ` [PATCH v4 04/10] udp_vu: Move virtqueue management from udp_vu_sock_recv() to its caller Laurent Vivier
2026-05-13 11:52 ` [PATCH v4 05/10] udp_vu: Pass iov explicitly to helpers instead of using file-scoped array Laurent Vivier
2026-05-13 11:52 ` [PATCH v4 06/10] checksum: Pass explicit L4 length to checksum functions Laurent Vivier
2026-05-13 11:52 ` [PATCH v4 07/10] pcap: Pass explicit L2 length to pcap_iov() Laurent Vivier
2026-05-13 11:52 ` [PATCH v4 08/10] vu_common: Pass explicit frame length to vu_flush() Laurent Vivier
2026-05-13 11:52 ` [PATCH v4 09/10] tcp: Pass explicit data length to tcp_fill_headers() Laurent Vivier
2026-05-13 11:52 ` [PATCH v4 10/10] vhost-user: Centralise Ethernet frame padding in vu_collect() and vu_pad() Laurent Vivier
2026-05-14 1:24 ` David Gibson
2026-05-20 0:52 ` Stefano Brivio [this message]
2026-05-20 15:34 ` [PATCH v4 00/10] vhost-user: Preparatory series for multiple iovec entries per virtqueue element Stefano Brivio
2026-05-20 16:07 ` Stefano Brivio
2026-05-20 16:18 ` Stefano Brivio
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260520025208.5f31e61e@elisabeth \
--to=sbrivio@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=jmaloy@redhat.com \
--cc=lvivier@redhat.com \
--cc=passt-dev@passt.top \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://passt.top/passt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).