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=202410 header.b=h2EeUfhR; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id A6F825A061C for ; Tue, 29 Oct 2024 05:18:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202410; t=1730175480; bh=jLL89R9L4/LuNSIkzqRAZndc3gcqlfKrbZ7lpvl2me0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=h2EeUfhRWjoj5uMqML6tNxjjc1kyzPwk/VlS7DsGtlNgueXTlx0ohF/daTdiG+Zps jsyc5PYtscKJKAHHnfFC/Nyl7hec75j6pt2jQQ+PhvhVNOmhW/nUJTJGa1xZZzi6MW vNfF77ZKS6AhObOs5XSg/toOAVGtdAkyZk4FBt999v/akdfSHTMT42Dtrg+OFYd7FR Dmd2+y+k7bStNdTxVu8Vd7w6YO1sW373bULLNzYaYLOb4RzuoihJd963XNPyd4pF9A hrk2MeuEIaFQw1JEEvcsC9bwKkWtYQUab9vRC6Y+rYCVKDYvSKXYp10Jfzb41euJZO IcyVKSUQnIudw== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4XcxnN4Kqxz4wcy; Tue, 29 Oct 2024 15:18:00 +1100 (AEDT) Date: Tue, 29 Oct 2024 15:07:56 +1100 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH 1/7] tcp: Pass TCP header and payload separately to tcp_update_check_tcp[46]() Message-ID: References: <20241028094050.1609090-1-david@gibson.dropbear.id.au> <20241028094050.1609090-2-david@gibson.dropbear.id.au> <20241028194254.71df8d2f@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="z46bYAD7cru8CK7q" Content-Disposition: inline In-Reply-To: Message-ID-Hash: Y3HZX5S5JZMU4QL2EWUQ7KSTQH37MUYW X-Message-ID-Hash: Y3HZX5S5JZMU4QL2EWUQ7KSTQH37MUYW 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: Laurent Vivier , 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: --z46bYAD7cru8CK7q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 29, 2024 at 02:02:25PM +1100, David Gibson wrote: > On Mon, Oct 28, 2024 at 07:42:54PM +0100, Stefano Brivio wrote: > > On Mon, 28 Oct 2024 20:40:44 +1100 > > David Gibson wrote: > >=20 > > > Currently these expects both the TCP header and payload in a single I= OV, > > > and goes to some trouble to locate the checksum field within it. In = the > > > current caller we've already know where the TCP header is, so we migh= t as > > > well just pass it in. This will need to work a bit differently for > > > vhost-user, but that code already needs to locate the TCP header for = other > > > reasons, so again we can just pass it in. > >=20 > > We couldn't do this, and also what you're now doing in 5/7, because > > with vhost-user the TCP header is not aligned, so we can't pass it > > around as a pointer, see: > >=20 > > > > https://archives.passt.top/passt-dev/ZeUpxEY-sn64NLE5@zatzit/ > >=20 > > and following. That one is about IP headers, but the same applies to > > TCP and UDP headers. >=20 > Hrm. I'm aware it theoretically need not be aligned, but I thought it > was in practice.. and that we were already relying on that. >=20 > In fact, I'm pretty sure the second part is true, although more subtly > than here. v8 of the vhost-user patches calls tcp_fill_headers[46]() > with the bp parameter set to the offset of the TCP header. If > creating a tcphdr * there is a problem, then creating a tcp_payload_t > * can't be any better. >=20 > > Of course the current solution is not elegant and it would be nice to > > find another way to deal with it, but we couldn't come up with anything > > better back then. > >=20 > > The rest of the series looks good to me, but I'm afraid that without > > this one and 5/7 the other changes will be a bit more complicated to > > implement (if at all possible). >=20 > Definitely. I have so ideas for approaches more robust to > misalignment, but they're substantially more complicated. I was > hoping we could avoid it at least for now. I had a closer look at that earlier message now. I believe at the time I was aiming for fully robust handling of misaligned user buffers. AIUI, we've given up on that for the time being: instead we'll just *test* for suitable alignment and we can do the hard work of handling it if it ever arises in practice. --=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 --z46bYAD7cru8CK7q Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmcgX40ACgkQzQJF27ox 2GcmQA/+KPSv9HBOyAEASyeEPJR3Y+GHSQw6F1YN8BdFl/KYBnZ7XAEittbEZ/7c /dQGyG9Os6XnDOXTqf5B9macSG5eLTslceA2zoNMx+shWBLRSIXjEUsqydOr0j2T V8zQJb2EFe1U6LLd5CV3AqGY01H8uEVWeO3NkMbMtF+2C1SMpb4mO8qc/JwrHlHH 06K2AAzex5F7z1eOisoNaSjFg2js+0dly4PrnX3PNR0j+WrSXdCCGOWXMaFqyhCc B2gvASUgM6G7Fw16FS51OXQF7zd9XoX0yDHZB/gvyEAT+rOqBzkJihl8BkhxehqC VJXgS/5LQ9VQHuzoMRS99JyZI1EzYQShseVk7+5sRzl0SuTecwC85mtKcm/LTYv9 XnNJfx2HJP2voytODVe3FC4vVffoUlDoHawWNpaNh816cWweY36CQv69Ow9HrJA9 nRWBZyX/5jIi6jiR663au6JeF37fAzA9O/G9Y0N0XgLm9H0KdHluSbisIYYltx22 7NFssuabLUrWPtBS6PqLONa1JjagfaNkke3KCKOho/GO5r56vrtzWE2HKoN6QN5v nz6avsZWt4ebNHX2edJsZk4hVjPsqqtPMCiyfeVoVnP444aZikO8A/dn7bheQP74 r3wpnJr5bk0P9iGQUANAPUwKPRqoY2OHamlwUae8nn5SqgN+Jw4= =Aruj -----END PGP SIGNATURE----- --z46bYAD7cru8CK7q--