From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=vivier.eu Authentication-Results: passt.top; dkim=pass (2048-bit key; unprotected) header.d=vivier.eu header.i=laurent@vivier.eu header.a=rsa-sha256 header.s=s1-ionos header.b=OsWprK9X; dkim-atps=neutral Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.74]) by passt.top (Postfix) with ESMTPS id 645875A004E for ; Mon, 23 Feb 2026 10:57:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vivier.eu; s=s1-ionos; t=1771840628; x=1772445428; i=laurent@vivier.eu; bh=Dzb8IVMHm/ZiT0XQzHTwHwunOaR5ixWunBBVMV6iBNM=; h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To:Cc: References:From:In-Reply-To:Content-Type: Content-Transfer-Encoding:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=OsWprK9XvwjvmNQ68Lz5Me4UtEqy439Z1K0iDBU5cp+VjT912twkX/+TdBSLYZtb TDNuWpoPVUm5JRqvx8Qxny05/0k8ToGVeEWizcpD0NgwVvCtZuYUXq19CSm2Rmr9y DAqSoURA4jgrp27g+xLj5lBab9vv7p2+iEey6fgeMRkiTj4k9Bvbj2fo/fdQPm44s k6JdbZwhLm8/fRKVBjuZCC6EzHPBzfWXV7hjTYhisc/C4Ch52PrwUcyUE6oa1v/Pg WVnqjgZJEm8ZLuypH+KNMKqEaUtnZcnnhzneUp7tQJxAZRM7O/DLeYlLt2ooUIZ6U yJ0Zi2Y8iuqvYvh+Lg== X-UI-Sender-Class: 55c96926-9e95-11ee-ae09-1f7a4046a0f6 Received: from [192.168.1.24] ([92.153.144.197]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.184]) with ESMTPSA (Nemesis) id 1M27ix-1vsXwj0fE1-002zEq; Mon, 23 Feb 2026 10:57:08 +0100 Message-ID: <6bdd7a8c-bdcb-43d8-a03f-d0a2f9468316@vivier.eu> Date: Mon, 23 Feb 2026 10:57:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] tcp_vu, udp_vu: Account for virtio net header in minimum frame size To: Stefano Brivio , Laurent Vivier References: <20260212113932.1047788-1-lvivier@redhat.com> <20260212113932.1047788-3-lvivier@redhat.com> <20260215115609.32cb69b0@elisabeth> Content-Language: en-US From: Laurent Vivier In-Reply-To: <20260215115609.32cb69b0@elisabeth> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:ZC7TtLC0w4Yw0Yko5EpWSF/iTXRt89eLbKKXwivxkpEfUCnzrga ugDy9Kl/Z+NLScZ+CHxc6jVOcub5DyHGS/8RzwudRU/3tFL8Y6ay4fzH45a4Vy48Qog64lX 9KEUiNOsU3O5q0xe9C0Z98Gun1q43iCypCrJi6XtWtK1lpo7Myy5zCDvCv7mJbH4AVIn7cA GrKUoPUjYIencNrYHfjOQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:FJv4qlN7XmY=;Egy7qkp4/CMW/jo1+6G8O3dWMZg hroM8ywBeJrB6Pk5JtUvvV0+SIB99wHMHknUaR3I6OxzvQZ165JqgIOqFQCu8s8RsHWLvhGjb LwOpasgi+jcOBMY5GUu+GbeW7Hebhw9IrK1Yj8bnFPgWYxIplZ2DCXV0MujOjJ91HfSQPyjkE aBd5/ZPh1OElcE4eWla13L8NTgngSgH3DOnO5tEMTbCq4kDXPbqJdUBlrYdJ/+dlZ2eZKef8x pX43BzzblO0pInhL3h6y0lOiY/+Ase4sC0Hg8RkHBBcj/WkHd8/7I0UHQQ+DIGQCSZ5b25Xmq eOksBLcdszGmWBKxIXRiX97fwPxZZcvHj0XKqyGew4vjXL5hg33/8NXPhTxLZ6v86bz4Vjok7 ULylPWXfvuyQo5WIP59vV936+l2ZmUPRvceB4Ry08xQfhDb77fMkX9DdpbEly0VxhcvGDB0TH JRoRsVBO8+ephT5leLzn3IWO2XDmCImrnomCnjoban1DErecGz64QVg9t6U82by3RoLFN18F1 dey4DGh+U3NCylw3p8b+kRnmMqc0QwtoMiobYmOk8I+5+wDKwUC3t36ChhlSCq1m7yxAro3C7 ZCY0xaw1BanOwesWpXfloL0yprnIsRpo0+ht7o1RDky69KJUV4cJffyByrcpNWvMC81mNGyjW 9qaR+AkfPnD3pQKqZUS1vXCVBSpevSKXvrV2NM15SxqBFyWhX/XN6/1OkvN+VfuWXZnofipO5 yCjdr1qb6ZuRJx7/M/P43M+r2qq6U+ctoIGocfdUX1Raw4vyziidmDHTHOTNTI1D7S+x0JqeA 1aJNdGH3RTOToLrpc1uS6FqdfM73TQOX9FD6os18YybCaddTiR4RqMsfpoW0G5p8IueYLbu2v eaHQg/DODJd3Ai/jAiEUtbP0VSxadsuleAfSCwvcjicRuTy5Nc8eK8cyFC25BieSf4N6gwuls U5s0wCUN1+J4TSCsgKQZpCLXNf60XFCX8DwjYPOtyLgJmTcMs/ciPo8Pc7UyTZj7eKNZkqyxa 8TpLGFZrz4p4wxxb+xk25wmA6GlQi9BReKwIsH+oov7T/8Bzk0UfHpBmd/JKohmz9Yx0YMw2n BOlbCjuRirSz5NgptVyUeD0QYO5hmulEAfAnCY6mtvIyWv+o2O/fyXTMLDeemQY1m/a8eXHOx tZfpi/cZYjD75KZd3ktfpt3qsZaT2VA1n29UGrn17lOXYHBquENnWuLNZhTAcQt2bA9vfOFRz 5ZRISh+SiI9dT2rjfEpJ3Ze1uwtmWFqnLGK2wNZ4OxO/Sn8XZyZvXRtwyWGxboRrLuXDECoj6 sDfW0LiuOBalkMvZDdCrItr7oCobxMIR0K33PztlK+UoR2F6nEmNzZBQGPshD+Y+Pu1KZbEFF xfYJsqN8gJe8qzOIujb51T1H1lf2ifrJsB3/k7fYe5x6zc4lEJp83sPbq7JTlAINWTgzgwwpl +nntJkkT8taoQ0WOVXCxHsf4qi1I9+Aot6IQ7uB92UAcC3x24nX5lH/EpQhxjXsza/O0zE68S 13JcQlbm6z01qUkAudmheyRspZsV5Nrmd11+TqfjdKrp0+Ky8trUbaTL+v4R08XouaQj7v6+B 6Syi/BSXgC1UWCUcm5zR1xpQvjH3di4KEhcIZrNRmINoMeZCLhRKtTpGzVClUlr7R9flOCEW+ 2Od6LJdznwE1f+bdCaYQAU5vUYYYRoebG1Rvlj9dGRFmDh+9yZ9NSbmtIBpOHfIIbejZOWIQb m3tpH0YXx2+J103G4vEyGwKOfMCoSb+QA2LosDVFVx9g6liAfZZK6pwblgh2MqSLvaxA3f9sv fll+ Message-ID-Hash: I2WRTXMKOQQS2LKCXQXZW7YDNRQWXTDV X-Message-ID-Hash: I2WRTXMKOQQS2LKCXQXZW7YDNRQWXTDV X-MailFrom: laurent@vivier.eu 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 2/15/26 11:56, Stefano Brivio wrote: > On Thu, 12 Feb 2026 12:39:32 +0100 > Laurent Vivier wrote: >=20 >> In the vhost-user paths, the buffers provided by the virtio queue >> include the virtio net header (VNET_HLEN) prepended to the Ethernet >> frame. The minimum size checks using ETH_ZLEN must therefore account >> for this additional header length, otherwise we underestimate the >> minimum buffer size needed. >> >> Use ETH_ZLEN + VNET_HLEN instead of bare ETH_ZLEN in vu_collect() >> calls and the corresponding ASSERT() checks. >> >> Fixes: 0cb8f9003654 ("tcp, udp: Pad batched frames for vhost-user modes= to 60 bytes (802.3 minimum)") >> Signed-off-by: Laurent Vivier >> --- >> tcp_vu.c | 8 ++++---- >> udp_vu.c | 2 +- >> 2 files changed, 5 insertions(+), 5 deletions(-) >> >> diff --git a/tcp_vu.c b/tcp_vu.c >> index f7bda4943e43..2d593d534d68 100644 >> --- a/tcp_vu.c >> +++ b/tcp_vu.c >> @@ -90,12 +90,12 @@ int tcp_vu_send_flag(const struct ctx *c, struct tc= p_tap_conn *conn, int flags) >> vu_set_element(&flags_elem[0], NULL, &flags_iov[0]); >> =20 >> elem_cnt =3D vu_collect(vdev, vq, &flags_elem[0], 1, >> - MAX(hdrlen + sizeof(*opts), ETH_ZLEN), NULL); >> + MAX(hdrlen + sizeof(*opts), ETH_ZLEN + VNET_HLEN), NULL); >> if (elem_cnt !=3D 1) >> return -1; >> =20 >> ASSERT(flags_elem[0].in_sg[0].iov_len >=3D >> - MAX(hdrlen + sizeof(*opts), ETH_ZLEN)); >> + MAX(hdrlen + sizeof(*opts), ETH_ZLEN + VNET_HLEN)); >> =20 >> vu_set_vnethdr(vdev, flags_elem[0].in_sg[0].iov_base, 1); >> =20 >> @@ -208,7 +208,7 @@ static ssize_t tcp_vu_sock_recv(const struct ctx *c= , struct vu_virtq *vq, >> =20 >> cnt =3D vu_collect(vdev, vq, &elem[elem_cnt], >> VIRTQUEUE_MAX_SIZE - elem_cnt, >> - MAX(MIN(mss, fillsize) + hdrlen, ETH_ZLEN), >> + MAX(MIN(mss, fillsize) + hdrlen, ETH_ZLEN + VNET_HLEN), >> &frame_size); >> if (cnt =3D=3D 0) >> break; >> @@ -302,7 +302,7 @@ static void tcp_vu_prepare(const struct ctx *c, str= uct tcp_tap_conn *conn, >> /* we guess the first iovec provided by the guest can embed >> * all the headers needed by L2 frame, including any padding >> */ >> - ASSERT(iov[0].iov_len >=3D MAX(hdrlen, ETH_ZLEN)); >> + ASSERT(iov[0].iov_len >=3D MAX(hdrlen, ETH_ZLEN + VNET_HLEN)); >=20 > This triggers in the passt_vu_in_ns/tcp, "TCP/IPv4: host to guest: big > transfer" test case, that is, the first time we connect to the guest > (probably on the initial SYN segment). >=20 > I didn't check why. After tcp_vu_sock_recv(), iov[0].iov_len is set to the size of hdrlen + re= ceived data,=20 it's why in tcp_vu_prepare() iov_len can be shorter than expected. As the = actual buffer=20 size is already guaranteed by vu_collect(), I think the ASSERT() should be= reverted to=20 ASSERT(iov[0].iov_len >=3D hdrlen). Moreover there is a problem with vu_pad() in tcp_vu.c that includes the VN= ET_HLEN (it=20 should not), see udp_vu.c I'm fixing that and send a new version. I was not able to reproduce the pr= oblem so I rely=20 on you to test it. Thanks, Laurent