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=BQECRnFL; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id C6F8D5A0262 for ; Tue, 17 Mar 2026 17:19:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1773764342; 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:autocrypt:autocrypt; bh=W0zXLxv78iArdD4ye5M+9btNrQGoPie0JfRdajHATx4=; b=BQECRnFLW2u8J8bhoT4GYv4hKYFz0SjFqCBAPx+b6bAGRmfO7wbjHL9DmKTY6IPJstbYO6 rjZ7W7ZvQIzx1F2WXIJGCdWyJfAZ1rDX3CIqQ8CyHNVGiRCuS1vVDoPulcvXp8QD3r2+LN E3gX/qTYTpdFZVts4lLjloQcrAqBUFI= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-641-SKL9w3A2MtKagsT2Yg9RbA-1; Tue, 17 Mar 2026 12:19:01 -0400 X-MC-Unique: SKL9w3A2MtKagsT2Yg9RbA-1 X-Mimecast-MFC-AGG-ID: SKL9w3A2MtKagsT2Yg9RbA_1773764340 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-4853553944fso504055e9.0 for ; Tue, 17 Mar 2026 09:19:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773764340; x=1774369140; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=W0zXLxv78iArdD4ye5M+9btNrQGoPie0JfRdajHATx4=; b=ms6m57kgfaahnoAodIKrb+U/4PFJLLqfp9O7rBWk2lU+zRvMDTk6s3VU9zXjzwTTiJ rBg5QSJBtBIcfqYyMk0VOqCwS/mqCLf0h4cvzOAu/Z0TrS8f7J7SqjAHBanuO1rwDPAn a5UAgu+jUDfEbBdcsLL4tqtAfbVu3uBK/3cRfHqpPqBfXZgiCLVkJ7pSa/oPqNw8VVmV Omf5xyVAQHzt3XHRRIYfVgCNCyFFiwMsQ/xkt3ta/yT6T0S7gURCbM1QPfQCWcnkpvjI P/y5ptAg+6AefBXhEuPEqKT/m7Ph6SyqY7E9Gv3GhFKccc8YpyYtDfyVdK1cfTG2+Dz2 VzDg== X-Gm-Message-State: AOJu0YxcjNsOeatuejFuw89NIxpFbJKG7JllfP3T+7OkmK8YyQK4Ql4o KGg+Ejj2Pm5GXCXfgDBTpYAUlXoa5nagfA8y6QJ8JMC6TVcLjiA4rgORYUka4rpfCm5CHUSCMvz +ybRQtOUnLbdpIkqxkFmpjLKwCo0m1ppTEWnldORxniRHJgBNK0D4uA== X-Gm-Gg: ATEYQzxfNPC9rxZC+y4/sOwueqgVR7WFegjzHMlRNjlwa9Kj3FYsb8jyci26OTxNyku SJ5QhPsYViMbvtbCGVZ8f2h/L474JBW6v/NnoQ7WQYZ26GWaEZFXufcuoWxN4w20G8ckiE6T8Oi cEfs5RIAfiTsQGj7lo/kwwmTG+JA6mpUjO2a4rcLjYnIPzQgjSEnL3BLzqMUJILpXYO2ZkjtRzZ Cl2JkuM2IISeluOj2EVObHg47zets5uNoEQ301FZAiVDXam99XvGbj4TgKpfhS6uKIgDUS1zL6p 4zRRNUW/VbVyHKmsSOol3KvMDa6dW1UBZjVesdR+8b0P1eCG8qxQOAT7q7FMi8/sCzYgJD1y0JX zQrxMA9zwLmvQlG2h1pKD+vDCD9DKKfxhhs6sRnCaHnyFXRxH+TZRlOKviERJbUaCVg== X-Received: by 2002:a05:600c:4713:b0:485:3cef:d6ea with SMTP id 5b1f17b1804b1-486f40c8f15mr4095395e9.13.1773764339981; Tue, 17 Mar 2026 09:18:59 -0700 (PDT) X-Received: by 2002:a05:600c:4713:b0:485:3cef:d6ea with SMTP id 5b1f17b1804b1-486f40c8f15mr4094855e9.13.1773764339431; Tue, 17 Mar 2026 09:18:59 -0700 (PDT) Received: from ?IPV6:2a01:e0a:e10:ef90:4326:a36e:a7cb:624b? ([2a01:e0a:e10:ef90:4326:a36e:a7cb:624b]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48634a7ac93sm57167985e9.2.2026.03.17.09.18.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Mar 2026 09:18:59 -0700 (PDT) Message-ID: <0ad98126-2a3b-44a8-b1f2-ab15400f3f97@redhat.com> Date: Tue, 17 Mar 2026 17:18:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/3] vu_common: Move iovec management into vu_collect() To: Stefano Brivio References: <20260313182618.4157365-1-lvivier@redhat.com> <20260313182618.4157365-4-lvivier@redhat.com> <20260317162354.117a8604@elisabeth> From: Laurent Vivier Autocrypt: addr=lvivier@redhat.com; keydata= xsFNBFYFJhkBEAC2me7w2+RizYOKZM+vZCx69GTewOwqzHrrHSG07MUAxJ6AY29/+HYf6EY2 WoeuLWDmXE7A3oJoIsRecD6BXHTb0OYS20lS608anr3B0xn5g0BX7es9Mw+hV/pL+63EOCVm SUVTEQwbGQN62guOKnJJJfphbbv82glIC/Ei4Ky8BwZkUuXd7d5NFJKC9/GDrbWdj75cDNQx UZ9XXbXEKY9MHX83Uy7JFoiFDMOVHn55HnncflUncO0zDzY7CxFeQFwYRbsCXOUL9yBtqLer Ky8/yjBskIlNrp0uQSt9LMoMsdSjYLYhvk1StsNPg74+s4u0Q6z45+l8RAsgLw5OLtTa+ePM JyS7OIGNYxAX6eZk1+91a6tnqfyPcMbduxyBaYXn94HUG162BeuyBkbNoIDkB7pCByed1A7q q9/FbuTDwgVGVLYthYSfTtN0Y60OgNkWCMtFwKxRaXt1WFA5ceqinN/XkgA+vf2Ch72zBkJL RBIhfOPFv5f2Hkkj0MvsUXpOWaOjatiu0fpPo6Hw14UEpywke1zN4NKubApQOlNKZZC4hu6/ 8pv2t4HRi7s0K88jQYBRPObjrN5+owtI51xMaYzvPitHQ2053LmgsOdN9EKOqZeHAYG2SmRW LOxYWKX14YkZI5j/TXfKlTpwSMvXho+efN4kgFvFmP6WT+tPnwARAQABzSNMYXVyZW50IFZp dmllciA8bHZpdmllckByZWRoYXQuY29tPsLBeAQTAQIAIgUCVgVQgAIbAwYLCQgHAwIGFQgC CQoLBBYCAwECHgECF4AACgkQ8ww4vT8vvjwpgg//fSGy0Rs/t8cPFuzoY1cex4limJQfReLr SJXCANg9NOWy/bFK5wunj+h/RCFxIFhZcyXveurkBwYikDPUrBoBRoOJY/BHK0iZo7/WQkur 6H5losVZtrotmKOGnP/lJYZ3H6OWvXzdz8LL5hb3TvGOP68K8Bn8UsIaZJoeiKhaNR0sOJyI YYbgFQPWMHfVwHD/U+/gqRhD7apVysxv5by/pKDln1I5v0cRRH6hd8M8oXgKhF2+rAOL7gvh jEHSSWKUlMjC7YwwjSZmUkL+TQyE18e2XBk85X8Da3FznrLiHZFHQ/NzETYxRjnOzD7/kOVy gKD/o7asyWQVU65mh/ECrtjfhtCBSYmIIVkopoLaVJ/kEbVJQegT2P6NgERC/31kmTF69vn8 uQyW11Hk8tyubicByL3/XVBrq4jZdJW3cePNJbTNaT0d/bjMg5zCWHbMErUib2Nellnbg6bc 2HLDe0NLVPuRZhHUHM9hO/JNnHfvgiRQDh6loNOUnm9Iw2YiVgZNnT4soUehMZ7au8PwSl4I KYE4ulJ8RRiydN7fES3IZWmOPlyskp1QMQBD/w16o+lEtY6HSFEzsK3o0vuBRBVp2WKnssVH qeeV01ZHw0bvWKjxVNOksP98eJfWLfV9l9e7s6TaAeySKRRubtJ+21PRuYAxKsaueBfUE7ZT 7zfOwU0EVgUmGQEQALxSQRbl/QOnmssVDxWhHM5TGxl7oLNJms2zmBpcmlrIsn8nNz0rRyxT 460k2niaTwowSRK8KWVDeAW6ZAaWiYjLlTunoKwvF8vP3JyWpBz0diTxL5o+xpvy/Q6YU3BN efdq8Vy3rFsxgW7mMSrI/CxJ667y8ot5DVugeS2NyHfmZlPGE0Nsy7hlebS4liisXOrN3jFz asKyUws3VXek4V65lHwB23BVzsnFMn/bw/rPliqXGcwl8CoJu8dSyrCcd1Ibs0/Inq9S9+t0 VmWiQWfQkz4rvEeTQkp/VfgZ6z98JRW7S6l6eophoWs0/ZyRfOm+QVSqRfFZdxdP2PlGeIFM C3fXJgygXJkFPyWkVElr76JTbtSHsGWbt6xUlYHKXWo+xf9WgtLeby3cfSkEchACrxDrQpj+ Jt/JFP+q997dybkyZ5IoHWuPkn7uZGBrKIHmBunTco1+cKSuRiSCYpBIXZMHCzPgVDjk4viP brV9NwRkmaOxVvye0vctJeWvJ6KA7NoAURplIGCqkCRwg0MmLrfoZnK/gRqVJ/f6adhU1oo6 z4p2/z3PemA0C0ANatgHgBb90cd16AUxpdEQmOCmdNnNJF/3Zt3inzF+NFzHoM5Vwq6rc1JP jfC3oqRLJzqAEHBDjQFlqNR3IFCIAo4SYQRBdAHBCzkM4rWyRhuVABEBAAHCwV8EGAECAAkF AlYFJhkCGwwACgkQ8ww4vT8vvjwg9w//VQrcnVg3TsjEybxDEUBm8dBmnKqcnTBFmxN5FFtI WlEuY8+YMiWRykd8Ln9RJ/98/ghABHz9TN8TRo2b6WimV64FmlVn17Ri6FgFU3xNt9TTEChq AcNg88eYryKsYpFwegGpwUlaUaaGh1m9OrTzcQy+klVfZWaVJ9Nw0keoGRGb8j4XjVpL8+2x OhXKrM1fzzb8JtAuSbuzZSQPDwQEI5CKKxp7zf76J21YeRrEW4WDznPyVcDTa+tz++q2S/Bp P4W98bXCBIuQgs2m+OflERv5c3Ojldp04/S4NEjXEYRWdiCxN7ca5iPml5gLtuvhJMSy36gl U6IW9kn30IWuSoBpTkgV7rLUEhh9Ms82VWW/h2TxL8enfx40PrfbDtWwqRID3WY8jLrjKfTd R3LW8BnUDNkG+c4FzvvGUs8AvuqxxyHbXAfDx9o/jXfPHVRmJVhSmd+hC3mcQ+4iX5bBPBPM oDqSoLt5w9GoQQ6gDVP2ZjTWqwSRMLzNr37rJjZ1pt0DCMMTbiYIUcrhX8eveCJtY7NGWNyx FCRkhxRuGcpwPmRVDwOl39MB3iTsRighiMnijkbLXiKoJ5CDVvX5yicNqYJPKh5MFXN1bvsB kmYiStMRbrD0HoY1kx5/VozBtc70OU0EB8Wrv9hZD+Ofp0T3KOr1RUHvCZoLURfFhSQ= In-Reply-To: <20260317162354.117a8604@elisabeth> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: YN5MfVZ9DMRL4WXbUutGldAOAjXCwhoDTSTGPaTr-zY_1773764340 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: IHRTGL6PRADFBNCZ2NXTPXWO7I22ZZNN X-Message-ID-Hash: IHRTGL6PRADFBNCZ2NXTPXWO7I22ZZNN 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: passt-dev@passt.top 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: On 3/17/26 16:23, Stefano Brivio wrote: > On Fri, 13 Mar 2026 19:26:18 +0100 > Laurent Vivier wrote: > >> Previously, callers had to pre-initialize virtqueue elements with iovec >> entries using vu_set_element() or vu_init_elem() before calling >> vu_collect(). This meant each element owned a fixed, pre-assigned iovec >> slot. >> >> Move the iovec array into vu_collect() as explicit parameters (in_sg, >> max_in_sg, and in_num), letting it pass the remaining iovec capacity >> directly to vu_queue_pop(). A running current_iov counter tracks >> consumed entries across elements, so multiple elements share a single >> iovec pool. The optional in_num output parameter reports how many iovec >> entries were consumed, allowing callers to track usage across multiple >> vu_collect() calls. >> >> This removes vu_set_element() and vu_init_elem() which are no longer >> needed, and is a prerequisite for multi-buffer support where a single >> virtqueue element can use more than one iovec entry. For now, callers >> assert the current single-iovec-per-element invariant until they are >> updated to handle multiple iovecs. >> >> Signed-off-by: Laurent Vivier > > This looks fine to me other than the comment about @in_num comment > (not sure if it makes sense) and pending clarification with David > regarding that argument to vu_collect(), so once that's sorted, if you > don't want further changes, I would apply it like it is. But I have a > question, just to be sure: > >> --- >> tcp_vu.c | 25 +++++++++++--------- >> udp_vu.c | 21 ++++++++++------- >> vu_common.c | 68 ++++++++++++++++++++++++----------------------------- >> vu_common.h | 22 +++-------------- >> 4 files changed, 60 insertions(+), 76 deletions(-) >> >> diff --git a/tcp_vu.c b/tcp_vu.c >> index fd734e857b3b..d470ab54bcea 100644 >> --- a/tcp_vu.c >> +++ b/tcp_vu.c >> @@ -87,13 +87,13 @@ int tcp_vu_send_flag(const struct ctx *c, struct tcp_tap_conn *conn, int flags) >> >> hdrlen = tcp_vu_hdrlen(CONN_V6(conn)); >> >> - vu_set_element(&flags_elem[0], NULL, &flags_iov[0]); >> - >> elem_cnt = vu_collect(vdev, vq, &flags_elem[0], 1, >> + &flags_iov[0], 1, NULL, >> MAX(hdrlen + sizeof(*opts), ETH_ZLEN + VNET_HLEN), NULL); >> if (elem_cnt != 1) >> return -1; >> >> + ASSERT(flags_elem[0].in_num == 1); >> ASSERT(flags_elem[0].in_sg[0].iov_len >= >> MAX(hdrlen + sizeof(*opts), ETH_ZLEN + VNET_HLEN)); >> >> @@ -148,9 +148,8 @@ int tcp_vu_send_flag(const struct ctx *c, struct tcp_tap_conn *conn, int flags) >> nb_ack = 1; >> >> if (flags & DUP_ACK) { >> - vu_set_element(&flags_elem[1], NULL, &flags_iov[1]); >> - >> elem_cnt = vu_collect(vdev, vq, &flags_elem[1], 1, >> + &flags_iov[1], 1, NULL, >> flags_elem[0].in_sg[0].iov_len, NULL); >> if (elem_cnt == 1 && >> flags_elem[1].in_sg[0].iov_len >= >> @@ -191,8 +190,8 @@ static ssize_t tcp_vu_sock_recv(const struct ctx *c, struct vu_virtq *vq, >> const struct vu_dev *vdev = c->vdev; >> struct msghdr mh_sock = { 0 }; >> uint16_t mss = MSS_GET(conn); >> + size_t hdrlen, iov_used; >> int s = conn->sock; >> - size_t hdrlen; >> int elem_cnt; >> ssize_t ret; >> int i; >> @@ -201,22 +200,26 @@ static ssize_t tcp_vu_sock_recv(const struct ctx *c, struct vu_virtq *vq, >> >> hdrlen = tcp_vu_hdrlen(v6); >> >> - vu_init_elem(elem, &iov_vu[DISCARD_IOV_NUM], VIRTQUEUE_MAX_SIZE); >> - >> + iov_used = 0; >> elem_cnt = 0; >> *head_cnt = 0; >> - while (fillsize > 0 && elem_cnt < VIRTQUEUE_MAX_SIZE) { >> + while (fillsize > 0 && elem_cnt < ARRAY_SIZE(elem) && >> + iov_used < VIRTQUEUE_MAX_SIZE) { >> + size_t frame_size, dlen, in_num; >> struct iovec *iov; >> - size_t frame_size, dlen; >> int cnt; >> >> cnt = vu_collect(vdev, vq, &elem[elem_cnt], >> - VIRTQUEUE_MAX_SIZE - elem_cnt, >> + ARRAY_SIZE(elem) - elem_cnt, >> + &iov_vu[DISCARD_IOV_NUM + iov_used], >> + VIRTQUEUE_MAX_SIZE - iov_used, &in_num, >> MAX(MIN(mss, fillsize) + hdrlen, ETH_ZLEN + VNET_HLEN), >> &frame_size); >> if (cnt == 0) >> break; >> + ASSERT((size_t)cnt == in_num); /* one iovec per element */ > > ...this (and the UDP equivalent) will trigger if there are multiple > iovecs per element, until the point the next pending series deals with > it. > > My assumption is that, if there multiple iovecs per element, we crash > in the way you reported in https://bugs.passt.top/show_bug.cgi?id=196 > anyway, so triggering this assertion here doesn't make it any worse for > the moment. > > Is my assumption correct, or do we risk adding additional cases where > we crash meanwhile? If we do, maybe it would be better to only merge > this patch with the next series. > You're right. The idea is to mark clearly that udp_vu.c and tcp_vu.c only manage 1 iovec per element. But they can be removed from this series if you prefer. Thanks, Laurent