From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=XHZV5Aad; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id CAF4B5A0262 for ; Wed, 01 Apr 2026 21:18:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1775071111; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=MgE0iIGzOOWzxLhl2TtCPWUAxWQBk8R6DdXrWaW4vF4=; b=XHZV5Aad0rY4z/9aaB/0L9uNGonvFx19HgsnHcbJlwTWXATJVHQ+XX5gCS/U0bLo3+eryD ci3S+S1f6k3AZIaLvHw/Kn0JJUgz/7MGLYYOOJxDC/l6GnWp6+3GZV6LkntjdN3NIhlklk qdZpMsb8m54OoOYHuu1jVyn9N8HWigY= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-372-G7RBtlnkNDKRWohMn-mrFg-1; Wed, 01 Apr 2026 15:18:30 -0400 X-MC-Unique: G7RBtlnkNDKRWohMn-mrFg-1 X-Mimecast-MFC-AGG-ID: G7RBtlnkNDKRWohMn-mrFg_1775071109 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id AD4801800627 for ; Wed, 1 Apr 2026 19:18:28 +0000 (UTC) Received: from lenovo-t14s.redhat.corp (headnet01.pony-001.prod.iad2.dc.redhat.com [10.2.32.101]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id E44A919560AB; Wed, 1 Apr 2026 19:18:27 +0000 (UTC) From: Laurent Vivier To: passt-dev@passt.top Subject: [PATCH 00/10] vhost-user: Preparatory series for multiple iovec entries per virtqueue element Date: Wed, 1 Apr 2026 21:18:16 +0200 Message-ID: <20260401191826.1782394-1-lvivier@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 5Ve21ZPa8UdG84bgDOMnreOfHZcmp0z-iD1yf6wxPcY_1775071109 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID-Hash: FFR77FV37OB3HXLLYTI3MVL6ATAUSLTK X-Message-ID-Hash: FFR77FV37OB3HXLLYTI3MVL6ATAUSLTK X-MailFrom: lvivier@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Laurent Vivier X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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_memcopy() 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. Laurent Vivier (10): iov: Introduce iov_memset() iov: Add iov_memcopy() to copy data between iovec arrays vu_common: Move vnethdr setup into vu_flush() udp_vu: Move virtqueue management from udp_vu_sock_recv() to its caller udp_vu: Pass iov explicitly to helpers instead of using file-scoped array checksum: Pass explicit L4 length to checksum functions pcap: Pass explicit L2 length to pcap_iov() vu_common: Pass explicit frame length to vu_flush() tcp: Pass explicit data length to tcp_fill_headers() vhost-user: Centralise Ethernet frame padding in vu_collect() and vu_pad() checksum.c | 35 ++++++----- checksum.h | 6 +- iov.c | 78 ++++++++++++++++++++++++ iov.h | 5 ++ pcap.c | 37 ++++++++--- pcap.h | 2 +- tap.c | 6 +- tcp.c | 14 +++-- tcp_buf.c | 3 +- tcp_internal.h | 2 +- tcp_vu.c | 62 +++++++++---------- udp.c | 5 +- udp_vu.c | 162 ++++++++++++++++++++++++++----------------------- vu_common.c | 58 ++++++++++-------- vu_common.h | 5 +- 15 files changed, 304 insertions(+), 176 deletions(-) -- 2.53.0