public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
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


  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).