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=TI7NN1Ho; 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 D62D15A0265 for ; Wed, 15 Apr 2026 12:46:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1776250018; 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=D+HFY4slPEXDBs8YZXddmhvWfHFV8uFFjyif/iWhxt8=; b=TI7NN1HoLRqa1w4LAuiBcwga+4gg2J9np9MXev7suWLnwM88kKaF6ykwHIHKVSxAEDLK3P YmX6f6H4dfs8Vw9daF9QXe6bajOkxhjqHFc9hjK3iD0cf7cd76mRmhPzUdIiv6jyg44TFi dj7tGM2m5n+hkU2K51HEi2geazBC5NE= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-116-3X5XQZwROfuNCfYZUVf8GA-1; Wed, 15 Apr 2026 06:46:56 -0400 X-MC-Unique: 3X5XQZwROfuNCfYZUVf8GA-1 X-Mimecast-MFC-AGG-ID: 3X5XQZwROfuNCfYZUVf8GA_1776250015 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-43d03065782so4021828f8f.0 for ; Wed, 15 Apr 2026 03:46:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776250015; x=1776854815; 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=D+HFY4slPEXDBs8YZXddmhvWfHFV8uFFjyif/iWhxt8=; b=ocfX0iGBScYqID2QIHYcscSQuzy2TQEauwSMKCFxW/ZNt68KyYa7cL/c3hTFJlSAtn wAZueeXfiu/lsZ++FNQAeWAhWleDRcMGJgMoHL6+EuHuj9BY4Z4nBVKrA0ZfX+qP/aIj jGYqR7g9LdW76TSTmx2HAAKKY2Uqnkv3QXnVEqOfDU0f/LK+UoSP8AGJR+bA2foeH+py Seo7SwNR+vJxLrcCl5kR59UzwH9HU0TOb/4Z9QlQ//oxfdSdFrKz/yTdR3VrGCSp2Gyr zgFnQTrCIPCOkpZOozjIhf3U7dXAFCw9bjahPNtP3B2jfxWrZSyOqa4XXsXxi2/VZcee INpg== X-Gm-Message-State: AOJu0YwIeqFUWlrFfI1Ao2e7Awhx7CCsGNzcBMXDgbgYna4DYzwfCNhj 4PWpJaFcokIjDZTUEYaRgjCIZnMH/uGR8h56Vc9JQG46ocKWVQ8HBOZzUkItHcTtTwz0qK8bFoK r4wRajkPrTPzrgwGZswPDadY0f8R+XGnFgAbyr3r48jEbaFe1TTl2yWoGaL/HOw== X-Gm-Gg: AeBDiesS+eCn9YFSI+7udP/NeEE0O1kAbNlA7I6CHxBZJokicti9O/Yw7e28/NIx1kA ivxkdoOotGMSlIlkJVATNEIKeML0U+fR1xxMWJbjUR+h5PtZlcT6nSe4Trdz1E/Nr8S1+zcVFdn wN3G7chZDdpmtU9vVyHjmSdDMgWJEOVNMs0H5b1wgVhuuWOyxplos9adhcUvVjh2CRNyeUUZAXi rB5gYLSuc3eoyR3OPloRU14thrNUTZ1PkNhzshV30iC0Ox0+55RKHtLjgasBFJ9RjsV0BOpxQsx qfTUceYplHLmHVAo9D4HojQP395RJBej7WOX5jBm82MoDUE7odMbjTcXicnSrJ4dzC/8SA6cS6E P7NPkMR1CcbBnZOk2e/YiioxVWaisXQbdPreW X-Received: by 2002:a05:6000:2211:b0:43d:2f61:c4c8 with SMTP id ffacd0b85a97d-43d641e80c2mr31268812f8f.0.1776250014970; Wed, 15 Apr 2026 03:46:54 -0700 (PDT) X-Received: by 2002:a05:6000:2211:b0:43d:2f61:c4c8 with SMTP id ffacd0b85a97d-43d641e80c2mr31268755f8f.0.1776250014425; Wed, 15 Apr 2026 03:46:54 -0700 (PDT) Received: from [192.168.100.100] ([82.64.211.94]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43ead3d5ea9sm4349082f8f.21.2026.04.15.03.46.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Apr 2026 03:46:53 -0700 (PDT) Message-ID: <9be96a62-779b-4ccf-8c3a-da555c9270c3@redhat.com> Date: Wed, 15 Apr 2026 12:46:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 10/10] vhost-user: Centralise Ethernet frame padding in vu_collect() and vu_pad() To: David Gibson References: <20260403163811.3209635-1-lvivier@redhat.com> <20260403163811.3209635-11-lvivier@redhat.com> 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: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: WJKpHbKo5LA-zQcla74ckmG_c9Aop_K0RxVh9Ri079g_1776250015 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: B5X3MJPVYP6NCW5UWG3FL3GPO2IR4KY6 X-Message-ID-Hash: B5X3MJPVYP6NCW5UWG3FL3GPO2IR4KY6 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 4/10/26 09:28, David Gibson wrote: > On Fri, Apr 03, 2026 at 06:38:11PM +0200, Laurent Vivier wrote: >> The previous per-protocol padding done by vu_pad() in tcp_vu.c and >> udp_vu.c was only correct for single-buffer frames: it assumed the >> padding area always fell within the first iov, writing past its end >> with a plain memset(). >> >> It also required each caller to compute MAX(..., ETH_ZLEN + VNET_HLEN) >> for vu_collect() and to call vu_pad() at the right point, duplicating >> the minimum-size logic across protocols. >> >> Move the Ethernet minimum size enforcement into vu_collect() itself, so >> that enough buffer space is always reserved for padding regardless of >> the requested frame size. >> >> Rewrite vu_pad() to take a full iovec array and use iov_memset(), >> making it safe for multi-buffer (mergeable rx buffer) frames. >> >> In tcp_vu_sock_recv(), replace iov_truncate() with iov_skip_bytes(): >> now that all consumers receive explicit data lengths, truncating the >> iovecs is no longer needed. In tcp_vu_data_from_sock(), cap each >> frame's data length against the remaining bytes actually received from >> the socket, so that the last partial frame gets correct headers and >> sequence number advancement. >> >> Signed-off-by: Laurent Vivier >> --- >> iov.c | 1 - >> tcp_vu.c | 34 ++++++++++++++++++---------------- >> udp_vu.c | 14 ++++++++------ >> vu_common.c | 31 +++++++++++++++---------------- >> vu_common.h | 2 +- >> 5 files changed, 42 insertions(+), 40 deletions(-) >> >> diff --git a/iov.c b/iov.c >> index dabc4f1ceea3..28c6d40d2986 100644 >> --- a/iov.c >> +++ b/iov.c >> @@ -180,7 +180,6 @@ size_t iov_truncate(struct iovec *iov, size_t iov_cnt, size_t size) >> * Will write less than @length bytes if it runs out of space in >> * the iov >> */ >> -/* cppcheck-suppress unusedFunction */ >> void iov_memset(const struct iovec *iov, size_t iov_cnt, size_t offset, int c, >> size_t length) >> { >> diff --git a/tcp_vu.c b/tcp_vu.c >> index 8c1894dca7fe..2dfe14485eee 100644 >> --- a/tcp_vu.c >> +++ b/tcp_vu.c >> @@ -88,7 +88,7 @@ int tcp_vu_send_flag(const struct ctx *c, struct tcp_tap_conn *conn, int flags) >> >> elem_cnt = vu_collect(vdev, vq, &flags_elem[0], 1, >> &flags_iov[0], 1, NULL, >> - MAX(hdrlen + sizeof(*opts), ETH_ZLEN + VNET_HLEN), NULL); >> + hdrlen + sizeof(*opts), NULL); >> if (elem_cnt != 1) >> return -1; >> >> @@ -128,8 +128,6 @@ int tcp_vu_send_flag(const struct ctx *c, struct tcp_tap_conn *conn, int flags) >> return ret; >> } >> >> - l2len = hdrlen + optlen - VNET_HLEN; >> - iov_truncate(&flags_iov[0], 1, l2len + VNET_HLEN); >> payload = IOV_TAIL(flags_elem[0].in_sg, 1, hdrlen); >> >> if (flags & KEEPALIVE) >> @@ -138,17 +136,17 @@ int tcp_vu_send_flag(const struct ctx *c, struct tcp_tap_conn *conn, int flags) >> tcp_fill_headers(c, conn, eh, ip4h, ip6h, th, &payload, >> optlen, NULL, seq, !*c->pcap); >> >> - vu_pad(&flags_elem[0].in_sg[0], l2len); >> - >> + vu_pad(flags_elem[0].in_sg, 1, hdrlen + optlen); > > Is there a reason not to fold vu_pad() into vu_flush()? Yes, vu_pad() needs iovec while vu_flush() takes elements. See in TCP series, '[PATCH v5 3/4] tcp_vu: Support multibuffer frames in tcp_vu_sock_recv()' (20260403170419.3233031-4-lvivier@redhat.com): vu_pad(&iov[frame[i].idx_iovec], frame[i].num_iovec, dlen + hdrlen); vu_flush(vdev, vq, &elem[frame[i].idx_element], frame[i].num_element, dlen + hdrlen); > >> vu_flush(vdev, vq, flags_elem, 1, hdrlen + optlen); >> Thanks, Laurent