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=E6DToERs; 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 2F0195A026E for ; Fri, 03 Apr 2026 18:42:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1775234567; 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: in-reply-to:in-reply-to:references:references; bh=Z93avJ0O1WCU1WAEPQMmgHsaPfSI35SLvkwV7iB8zlE=; b=E6DToERssAVFcD3wU3pywoszvVL/A9TZy+WG7TVRq4sXlPwUoIYAFMMVnPno0F8+w7jG4K YDT7zE82f4KM5XQdyede2hhuo/DKTG/WZ4uS+cVUc+6JikIf0T9UTeO/WxUN6RhF3fpCq0 il3Ie9wF/LAM81tFQkMrvbnw2VLrngA= 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-422-sDMCqDWwNO6OX0swx24EOQ-1; Fri, 03 Apr 2026 12:42:45 -0400 X-MC-Unique: sDMCqDWwNO6OX0swx24EOQ-1 X-Mimecast-MFC-AGG-ID: sDMCqDWwNO6OX0swx24EOQ_1775234565 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-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 2EAA818005B9 for ; Fri, 3 Apr 2026 16:42:45 +0000 (UTC) Received: from lenovo-t14s.redhat.corp (headnet01.pony-001.prod.iad2.dc.redhat.com [10.2.32.101]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id A165B1800576; Fri, 3 Apr 2026 16:42:43 +0000 (UTC) From: Laurent Vivier To: passt-dev@passt.top Subject: [PATCH v7 1/3] udp_vu: Allow virtqueue elements with multiple iovec entries Date: Fri, 3 Apr 2026 18:42:39 +0200 Message-ID: <20260403164241.3212528-2-lvivier@redhat.com> In-Reply-To: <20260403164241.3212528-1-lvivier@redhat.com> References: <20260403164241.3212528-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: csvkk1DSVtlbc_I8UmVpq4ykGSvTrDFCDztqvkDA9QQ_1775234565 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit content-type: text/plain; charset="US-ASCII"; x-default=true Message-ID-Hash: MZN5OJIW4REDLGM5ISK6OGLQDMZPGG4Q X-Message-ID-Hash: MZN5OJIW4REDLGM5ISK6OGLQDMZPGG4Q 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: The previous code assumed a 1:1 mapping between virtqueue elements and iovec entries (enforced by an assert). Drop that assumption to allow elements that span multiple iovecs: track elem_used separately by walking the element list against the iov count returned after padding. This also fixes vu_queue_rewind() and vu_flush() to use the element count rather than the iov count. Use iov_tail_clone() in udp_vu_sock_recv() to handle header offset, replacing the manual base/len adjustment and restore pattern. Signed-off-by: Laurent Vivier --- udp_vu.c | 31 ++++++++++++++++--------------- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/udp_vu.c b/udp_vu.c index 30af64034516..16086e6c0c03 100644 --- a/udp_vu.c +++ b/udp_vu.c @@ -64,30 +64,25 @@ static size_t udp_vu_hdrlen(bool v6) */ static ssize_t udp_vu_sock_recv(struct iovec *iov, size_t *cnt, int s, bool v6) { + struct iovec msg_iov[*cnt]; struct msghdr msg = { 0 }; + struct iov_tail payload; size_t hdrlen, iov_used; ssize_t dlen; /* compute L2 header length */ hdrlen = udp_vu_hdrlen(v6); - /* reserve space for the headers */ - assert(iov[0].iov_len >= MAX(hdrlen, ETH_ZLEN + VNET_HLEN)); - iov[0].iov_base = (char *)iov[0].iov_base + hdrlen; - iov[0].iov_len -= hdrlen; + payload = IOV_TAIL(iov, *cnt, hdrlen); - /* read data from the socket */ - msg.msg_iov = iov; - msg.msg_iovlen = *cnt; + msg.msg_iov = msg_iov; + msg.msg_iovlen = iov_tail_clone(msg.msg_iov, payload.cnt, &payload); + /* read data from the socket */ dlen = recvmsg(s, &msg, 0); if (dlen < 0) return -1; - /* restore the pointer to the headers address */ - iov[0].iov_base = (char *)iov[0].iov_base - hdrlen; - iov[0].iov_len += hdrlen; - iov_used = iov_skip_bytes(iov, *cnt, MAX(dlen + hdrlen, VNET_HLEN + ETH_ZLEN), NULL); @@ -205,7 +200,7 @@ void udp_vu_sock_to_tap(const struct ctx *c, int s, int n, flow_sidx_t tosidx) } for (i = 0; i < n; i++) { - unsigned elem_cnt, elem_used; + unsigned elem_cnt, elem_used, j, k; size_t iov_cnt; ssize_t dlen; @@ -215,15 +210,21 @@ void udp_vu_sock_to_tap(const struct ctx *c, int s, int n, flow_sidx_t tosidx) if (elem_cnt == 0) break; - assert((size_t)elem_cnt == iov_cnt); /* one iovec per element */ - dlen = udp_vu_sock_recv(iov_vu, &iov_cnt, s, v6); if (dlen < 0) { vu_queue_rewind(vq, elem_cnt); break; } - elem_used = iov_cnt; /* one iovec per element */ + elem_used = 0; + for (j = 0, k = 0; k < iov_cnt && j < elem_cnt; j++) { + size_t iov_still_needed = iov_cnt - k; + + if (elem[j].in_num > iov_still_needed) + elem[j].in_num = iov_still_needed; + k += elem[j].in_num; + elem_used++; + } /* release unused buffers */ vu_queue_rewind(vq, elem_cnt - elem_used); -- 2.53.0