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=OZZHQSJv; 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 8516F5A0262 for ; Tue, 19 May 2026 17:56:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1779206179; 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=K8vqXjJbU/w4D5uvQP7jdwf+57AY8a3munsc6Xf0+wM=; b=OZZHQSJvMeJDLbeD8PMJP5ncMG30VfexbO7K0ZTKMVfwD8KP/y6K3GR6m1AwkrfKtNlN0F srNaZoQ2Y2wTf2xvUENXLijb8rLpQthqG8NCcalMDiven8dJNbXSRz8MOclN+G63FfdbG2 YH9y1OOgj8sSDVsPr4IlUs+M3DLEBAI= Received: from mx-prod-mc-08.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-614-AEeIQfnPPkSg26Ga6dCppA-1; Tue, 19 May 2026 11:56:16 -0400 X-MC-Unique: AEeIQfnPPkSg26Ga6dCppA-1 X-Mimecast-MFC-AGG-ID: AEeIQfnPPkSg26Ga6dCppA_1779206176 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (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-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id D7A0C18002D7 for ; Tue, 19 May 2026 15:56:15 +0000 (UTC) Received: from lenovo-t14s.redhat.corp (headnet01.pony-001.prod.iad2.dc.redhat.com [10.2.32.101]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 1A1D630001A2; Tue, 19 May 2026 15:56:14 +0000 (UTC) From: Laurent Vivier To: passt-dev@passt.top Subject: [PATCH v10 0/3] vhost-user,udp: Handle multiple iovec entries per virtqueue element Date: Tue, 19 May 2026 17:56:10 +0200 Message-ID: <20260519155613.3127607-1-lvivier@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 3U84UAKg9M8XGzrwDsibW9Y0_njOKxB35L3Iyl2i0z0_1779206176 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID-Hash: OHQDJEU7T6WUZ2NFIKOSCELXZIAYLI6F X-Message-ID-Hash: OHQDJEU7T6WUZ2NFIKOSCELXZIAYLI6F 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. Based-on: 20260513115218.1662850-1-lvivier@redhat.com v10: - udp_update_hdr4()/udp_update_hdr6(): take separate @uh pointer and @payload - udp_tap_prepare(): extract uh from UDP_IOV_PAYLOAD, @payload is UDP payload only - udp_vu_sock_recv(): extract UDP payload from the function - udp_vu_prepare(): take @payload as parameter, compute checksum conditionally via !*c->pcap instead of hardcoded true - udp_vu_csum(): removed v9: - iov_push_header_(): skip memcpy() when the source pointer already aliases the iov buffer - udp_update_hdr4()//udp_update_hdr6()/usp_csum(): update payload doc - udp_tap_prepare(): use existing (*tap_iov)[UDP_IOV_PAYLOAD] v8: - Add Reviewed-by from David for 1/3 and 2/3 - Remove VLA to use fixed size (VIRTQUEUE_MAX_SIZE) - Rename udp_frame to datagram - Use sizeof(uh) instead of sizeof(struct udphdr) - Push back uh in memory in udp_vu_csum() v7: - In udp_vu_sock_to_tap(), introduce iov_still_needed variable - Fix iov_tail @data doc comments in udp_vu_prepare()/udp_vu_csum() - Don't rewrap the virtio checksum comment in udp_update_hdr6() - Add NULL check for uh in udp_vu_csum() v6: - Rebased on top of [PATCH 00/10] vhost-user: Preparatory series for multiple iovec entries per virtqueue element v5: - This version doesn't change the padding system regarding v4, it's a complex task that will be addressed in another version - reorder patches and add new patches - remove IOV_PUT_HEADER()/with_header() and introduce IOV_PUSH_HEADER() - don't use the iov_tail to provide the headers to the functions - move vu_set_vnethdr() to vu_flush(), extract vu_queue_notify() - move vu_flush() inside loop in tcp_vu_data_from_sock() to flush data by frame and not by full data length 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 (3): udp_vu: Allow virtqueue elements with multiple iovec entries iov: Introduce IOV_PUSH_HEADER() macro udp: Pass iov_tail to udp_update_hdr4()/udp_update_hdr6() iov.c | 30 ++++++++++++ iov.h | 11 +++++ udp.c | 74 ++++++++++++++-------------- udp_internal.h | 6 ++- udp_vu.c | 129 +++++++++++++++++++------------------------------ 5 files changed, 131 insertions(+), 119 deletions(-) -- 2.54.0