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=ObejHDGK; 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 08DFF5A0626 for ; Mon, 23 Mar 2026 15:31:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1774276316; 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=IupYjsZSkigW9iv0gLkcCdsb9X/BMNK88RQMdCK7CXs=; b=ObejHDGK7IDL6ehuYnITPzL+C5c0M5mHxCXKH74VQ9Hnc+bveGoXfv74YGy8vZM9GKBVvM KT/+iRlYfDuws0KTAWmmyb7vY2jaC+iZhmm2+yu6v0tvKbj02TuJpXiAIMzBjo3fTSWTRK 5WgLAyJdEV4MCc0iTYH9G1ar5acUI4s= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-538-iMocM7F2N_uIZFo3q4S6jA-1; Mon, 23 Mar 2026 10:31:55 -0400 X-MC-Unique: iMocM7F2N_uIZFo3q4S6jA-1 X-Mimecast-MFC-AGG-ID: iMocM7F2N_uIZFo3q4S6jA_1774276314 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (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-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 8C2A0195609E for ; Mon, 23 Mar 2026 14:31:54 +0000 (UTC) Received: from lenovo-t14s.redhat.com (unknown [10.44.32.96]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 8D1AD180058C; Mon, 23 Mar 2026 14:31:53 +0000 (UTC) From: Laurent Vivier To: passt-dev@passt.top Subject: [PATCH v4 0/5] vhost-user,udp: Handle multiple iovec entries per virtqueue element Date: Mon, 23 Mar 2026 15:31:46 +0100 Message-ID: <20260323143151.538673-1-lvivier@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: jwmv2EF7HgmRey18HcB3u6XmzWap_ubq-dco5KdGT0Y_1774276314 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID-Hash: 67CO3Z3FP442DUPJ3ZQVQY3D6KW2VUWL X-Message-ID-Hash: 67CO3Z3FP442DUPJ3ZQVQY3D6KW2VUWL 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: 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. Currently, the RX (host to guest) path assumes a single iovec per element, which triggers: ASSERTION FAILED in virtqueue_map_desc (virtio.c:403): num_sg < max_num_sg This series reworks the UDP vhost-user receive path to support multiple iovec entries per element, fixing the iPXE crash. This series only addresses the UDP path. TCP vhost-user will be updated to use multi-iov elements in a subsequent series. v4: - rebase - replace ASSERT() by assert() v3: - include the series "Decouple iovec management from virtqueues elements" - because of this series, drop: "vu_common: Accept explicit iovec counts in vu_set_element()" "vu_common: Accept explicit iovec count per element in vu_init_elem()" "vu_common: Prepare to use multibuffer with guest RX" "vhost-user,udp: Use 2 iovec entries per element" - drop "vu_common: Pass iov_tail to vu_set_vnethdr()" as the specs insures a buffer is big enough to contain vnet header - introduce "with_header()" and merge "udp: Pass iov_tail to udp_update_hdr4()/udp_update_hdr6()" and "udp_vu: Use iov_tail in udp_vu_prepare()" to use it v2: - add iov_truncate(), iov_memset() - remove iov_tail_truncate() and iov_tail_zero_end() - manage 802.3 minimum frame size Laurent Vivier (5): vhost-user: Centralise Ethernet frame padding in vu_collect(), vu_pad() and vu_flush() udp_vu: Use iov_tail to manage virtqueue buffers udp_vu: Move virtqueue management from udp_vu_sock_recv() to its caller iov: Add IOV_PUT_HEADER() and with_header() to write header data back to iov_tail udp: Pass iov_tail to udp_update_hdr4()/udp_update_hdr6() iov.c | 47 +++++++++++ iov.h | 27 ++++++- tcp_vu.c | 22 ++---- udp.c | 129 ++++++++++++++++-------------- udp_internal.h | 6 +- udp_vu.c | 210 ++++++++++++++++++++++++------------------------- vu_common.c | 76 ++++++++++++------ vu_common.h | 2 +- 8 files changed, 310 insertions(+), 209 deletions(-) -- 2.53.0