From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202510 header.b=nUiipLKF; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id DB8E25A0619 for ; Fri, 05 Dec 2025 05:12:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202510; t=1764907949; bh=hylfHlg29iYU6aiUpZixNosR6iPf0836+VeMaljG3Dc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=nUiipLKFxS/5bKTha4bkL3yTz3MWHo+ZR5i98CC2qdVf1Ik1h+vXV8hGwH4t7kHt4 LK7FhLcrpz8OqMcfqyGo0Q0Fj30Tdl81iERKnItb2yEfrIEdZ/18H/CuZ8OJbeJOw1 yHdvPTsT0nQXrZ2hGn8DGQMKYrAXo4Dy38RRY/sOgoGdvv9d8bMn+KKrF8kr8vN9Iv AmUZWaDXZ6RcB26GPyfepE4HGRg/WQPLzUB0yKc1fWiTVJ4fcGvcOkMdzVm0DFdAcj t6o7b5vGFWITPPPrmSSrSNlZWPxQS/i8VbBfBDCctcG90rCVcO3rlNK0IXXAyNp7DN 8lr6t2SyuXRJA== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4dMydT0t2hz4wHW; Fri, 05 Dec 2025 15:12:29 +1100 (AEDT) Date: Fri, 5 Dec 2025 15:12:26 +1100 From: David Gibson To: Stefano Brivio Subject: Re: [RFC PATCH 5/5] tcp, udp: Pad batched frames for vhost-user modes to 60 bytes (802.3 minimum) Message-ID: References: <20251103101612.1412079-1-sbrivio@redhat.com> <20251103101612.1412079-6-sbrivio@redhat.com> <20251205015143.24f8d43e@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0we1yjK/jQmsuuD9" Content-Disposition: inline In-Reply-To: <20251205015143.24f8d43e@elisabeth> Message-ID-Hash: TKU6IQ4XVPYDWO5LHSTPP5Q7NL4NSPPK X-Message-ID-Hash: TKU6IQ4XVPYDWO5LHSTPP5Q7NL4NSPPK X-MailFrom: dgibson@gandalf.ozlabs.org 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, 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: --0we1yjK/jQmsuuD9 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 05, 2025 at 01:51:43AM +0100, Stefano Brivio wrote: > On Wed, 5 Nov 2025 14:49:59 +1100 > David Gibson wrote: >=20 > > On Mon, Nov 03, 2025 at 11:16:12AM +0100, Stefano Brivio wrote: > > > For both TCP and UDP, we request vhost-user buffers that are large > > > enough to reach ETH_ZLEN (60 bytes), so padding is just a matter of > > > increasing the appropriate iov_len and clearing bytes in the buffer > > > as needed. > > >=20 > > > Link: https://bugs.passt.top/show_bug.cgi?id=3D166 > > > Signed-off-by: Stefano Brivio =20 > >=20 > > I think this is correct, apart from the nasty bug Laurent spotted. > >=20 > > I'm less certain if this is the most natural way to do it. > >=20 > > > --- > > > tcp.c | 2 -- > > > tcp_internal.h | 1 + > > > tcp_vu.c | 27 +++++++++++++++++++++++++++ > > > udp_vu.c | 11 ++++++++++- > > > 4 files changed, 38 insertions(+), 3 deletions(-) > > >=20 > > > diff --git a/tcp.c b/tcp.c > > > index e91c0cf..039688d 100644 > > > --- a/tcp.c > > > +++ b/tcp.c > > > @@ -335,8 +335,6 @@ enum { > > > }; > > > #endif > > > =20 > > > -/* MSS rounding: see SET_MSS() */ > > > -#define MSS_DEFAULT 536 > > > #define WINDOW_DEFAULT 14600 /* RFC 6928 */ > > > =20 > > > #define ACK_INTERVAL 10 /* ms */ > > > diff --git a/tcp_internal.h b/tcp_internal.h > > > index 5f8fb35..d2295c9 100644 > > > --- a/tcp_internal.h > > > +++ b/tcp_internal.h > > > @@ -12,6 +12,7 @@ > > > #define BUF_DISCARD_SIZE (1 << 20) > > > #define DISCARD_IOV_NUM DIV_ROUND_UP(MAX_WINDOW, BUF_DISCARD_SIZE) > > > =20 > > > +#define MSS_DEFAULT /* and minimum */ 536 /* as it comes from minimu= m MTU */ > > > #define MSS4 ROUND_DOWN(IP_MAX_MTU - \ > > > sizeof(struct tcphdr) - \ > > > sizeof(struct iphdr), \ > > > diff --git a/tcp_vu.c b/tcp_vu.c > > > index 1c81ce3..7239401 100644 > > > --- a/tcp_vu.c > > > +++ b/tcp_vu.c > > > @@ -60,6 +60,29 @@ static size_t tcp_vu_hdrlen(bool v6) > > > return hdrlen; > > > } > > > =20 > > > +/** > > > + * tcp_vu_pad() - Pad 802.3 frame to minimum length (60 bytes) if ne= eded > > > + * @iov: iovec array storing 802.3 frame with TCP segment inside > > > + * @cnt: Number of entries in @iov > > > + */ > > > +static void tcp_vu_pad(struct iovec *iov, size_t cnt) > > > +{ > > > + size_t l2len, pad; > > > + > > > + ASSERT(iov_size(iov, cnt) >=3D sizeof(struct virtio_net_hdr_mrg_rxb= uf)); > > > + l2len =3D iov_size(iov, cnt) - sizeof(struct virtio_net_hdr_mrg_rxb= uf); =20 > >=20 > > Re-obtaining l2len from iov_size() seems kind of awkward, since the > > callers should already know the length - they've just used it to > > populate iov_len. >=20 > That's only the case for tcp_vu_send_flag() though, because > tcp_vu_data_from_sock() can use split buffers and iov_len of the first > element is not the same as the whole frame length. Yes, but.. > That is, you could (very much in theory) have iov_len set to 50 for the > first iov item, set to 4 for the second iov item, and the frame needs > padding, but you can't tell from the first iov item itself. Before we call tcp_vu_prepare() on that path, we've already calculated 'dlen' from iov_size, here we're calling iov_size a second time. >=20 > >=20 > > > + if (l2len >=3D ETH_ZLEN) > > > + return; =20 > >=20 > >=20 > > > + > > > + pad =3D ETH_ZLEN - l2len; > > > + > > > + /* tcp_vu_sock_recv() requests at least MSS-sized vhost-user buffer= s */ > > > + static_assert(ETH_ZLEN <=3D MSS_DEFAULT); =20 > >=20 > > So, this is true for the data path, but not AFAICT for the flags path. > >=20 > > There _is_ still enough space in this case, because we request space > > for (tcp_vu_hdrlen() + sizeof(struct tcp_syn_opts)) which works out to: > > ETH_HLEN 14 > > + IP header 20 > > + TCP header 20 > > + tcp_syn_opts 8 > > ---- > > 62 > ETH_ZLEN > >=20 > > But the comment and assert are misleading. >=20 > Dropped, in favour of: >=20 > > It seems like it would make more sense to clamp ETH_ZLEN as a lower > > length bound before we vu_collect() the buffers. >=20 > this. =F0=9F=91=8D > > Or indeed, like we should be calculating l2len already including the > > clamping. >=20 > That's not trivial to do for the data path, I think (see above). I > think it would be doable with a rework of the tcp_vu_data_from_sock() > loop but I'd say it's beyond the scope of this series. Yeah, fair enough. >=20 > > > + memset(&iov[cnt - 1].iov_base + iov[cnt - 1].iov_len, 0, pad); > > > + iov[cnt - 1].iov_len +=3D pad; > > > +} > > > + > > > /** > > > * tcp_vu_send_flag() - Send segment with flags to vhost-user (no pa= yload) > > > * @c: Execution context > > > @@ -138,6 +161,8 @@ int tcp_vu_send_flag(const struct ctx *c, struct = tcp_tap_conn *conn, int flags) > > > tcp_fill_headers(c, conn, NULL, eh, ip4h, ip6h, th, &payload, > > > NULL, seq, !*c->pcap); > > > =20 > > > + tcp_vu_pad(&flags_elem[0].in_sg[0], 1); > > > + > > > if (*c->pcap) { > > > pcap_iov(&flags_elem[0].in_sg[0], 1, > > > sizeof(struct virtio_net_hdr_mrg_rxbuf)); > > > @@ -456,6 +481,8 @@ int tcp_vu_data_from_sock(const struct ctx *c, st= ruct tcp_tap_conn *conn) > > > =20 > > > tcp_vu_prepare(c, conn, iov, buf_cnt, &check, !*c->pcap, push); > > > =20 > > > + tcp_vu_pad(iov, buf_cnt); > > > + > > > if (*c->pcap) { > > > pcap_iov(iov, buf_cnt, > > > sizeof(struct virtio_net_hdr_mrg_rxbuf)); > > > diff --git a/udp_vu.c b/udp_vu.c > > > index 099677f..1b60860 100644 > > > --- a/udp_vu.c > > > +++ b/udp_vu.c > > > @@ -72,8 +72,8 @@ static int udp_vu_sock_recv(const struct ctx *c, st= ruct vu_virtq *vq, int s, > > > { > > > const struct vu_dev *vdev =3D c->vdev; > > > int iov_cnt, idx, iov_used; > > > + size_t off, hdrlen, l2len; > > > struct msghdr msg =3D { 0 }; > > > - size_t off, hdrlen; > > > =20 > > > ASSERT(!c->no_udp); > > > =20 > > > @@ -116,6 +116,15 @@ static int udp_vu_sock_recv(const struct ctx *c,= struct vu_virtq *vq, int s, > > > iov_vu[idx].iov_len =3D off; > > > iov_used =3D idx + !!off; > > > =20 > > > + /* pad 802.3 frame to 60 bytes if needed */ > > > + l2len =3D *dlen + hdrlen - sizeof(struct virtio_net_hdr_mrg_rxbuf); > > > + if (l2len < ETH_ZLEN) { > > > + size_t pad =3D ETH_ZLEN - l2len; > > > + > > > + iov_vu[idx].iov_len +=3D pad; > > > + memset(&iov_vu[idx].iov_base + off, 0, pad); > > > + } > > > + > > > vu_set_vnethdr(vdev, iov_vu[0].iov_base, iov_used); > > > =20 > > > /* release unused buffers */ > > > --=20 > > > 2.43.0 >=20 > --=20 > Stefano >=20 --=20 David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson --0we1yjK/jQmsuuD9 Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmkyW6kACgkQzQJF27ox 2GegNA//SNTk0tJzBEzqgA1ZQc7jpLCJGDf5Ji04i3ukzCeJtkSA0iLI9gGJfClV v407MWOQgWK50bikf5cmciVNoFQ27jrDWLFIPaK+wK4vrvJgtVG+HuqrNZgtLcZ5 dgIQfR06/CIMymyv4gKIy9Dquib+yxX/kbTIgnPUcWrCfOejsHumljkY0mIu+irP yJqcjvhG4HYV2VzqRfrW3kUEt56oCM39YMCPwCuEPkjCcXIQmuD/0q7e0Dox97hX 1sHEjkJ08EV/PMTtC6OEC9Lxjmjd+I1CYoGJJRfJAv3KluANaQcZkgVnSCBxra3a egr96azsk7dDO4MsD+Hb1mVTcsmgqOFCsrAJdXMxPqj1RjosdEXpB0n4k8e3jm8h O21eTttm7p1dDcWXPp6ec5inIt7QbIMh+5R2IR7gA0H0vatwjdKXR583UEctaAJu PGcIRVUFHtoOsVDSD6rGd+xcOQwBBhBGdC8jOMk47rqyknU4I1PzYg9pvRsJPWzu ydPIlaHx6AtRy3XbSf93yFD2KUy/RFzcA8Ywd53ttKv4Mtf/KVIzbLBK8KETACbv sDJrl+CRs4zbtsSeaFVHPiy88F8gtIPb3uDMvEFC6L5G43aOHJFJOO7umKkz1V38 52YQ+wG1P7lk5mr6nMhwKftSf0i7RTgDE77nFhZc3jkGQLH7/8o= =Qgx7 -----END PGP SIGNATURE----- --0we1yjK/jQmsuuD9--