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=202602 header.b=AkBKU9A8; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 02AB05A0274 for ; Mon, 25 May 2026 11:38:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202602; t=1779701916; bh=dluZry/sgco0ApK9JUyP/MsxOBgatAnzNIqU89gPwRQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=AkBKU9A83YKsA72BYW9jjKzTBq9K1+LtsjkwVvI7Tz61Bzv0nXSy1sGDK54aawZ+d tb8RQaoIq2peCwnmHfqg/mK6SPI6eBOCPFlj219BDVqVYY/RiDO27cA1tMmh7nKdAx EBoRW15U5p4oe1nFZ8R1CZhZ+p6MSGAYuAOm1kYTJCq+jNr967Si4IOsueZh8o5fqD DZkOWl72oAlqcwpqqdRhRuzvXyRpWHr3fhGSVLTOPVal+HVgbKcrcN7BkO1BeKxKlw Y3wMw6kuQHiOi7IDz4NVU+6rKAq1329fWpM+otMaWSKpaxGVRLlhD+SEt0GS3STg5u UIW9IGKiNPtcg== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4gP9mr30BRz4wKB; Mon, 25 May 2026 19:38:36 +1000 (AEST) Date: Mon, 25 May 2026 19:35:37 +1000 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH v7 02/13] passt, pasta: Introduce unified multi-address data structures Message-ID: References: <20260413005319.3295910-1-jmaloy@redhat.com> <20260413005319.3295910-3-jmaloy@redhat.com> <20260515012832.547eadb6@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qkmk0QyV0frfHT8R" Content-Disposition: inline In-Reply-To: <20260515012832.547eadb6@elisabeth> Message-ID-Hash: YFVFHMPMZFULOWLJ7BIEHHTKVFG5BTQD X-Message-ID-Hash: YFVFHMPMZFULOWLJ7BIEHHTKVFG5BTQD 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: Jon Maloy , 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: --qkmk0QyV0frfHT8R Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 15, 2026 at 01:28:33AM +0200, Stefano Brivio wrote: > On Thu, 14 May 2026 16:30:16 +1000 > David Gibson wrote: >=20 > > On Sun, Apr 12, 2026 at 08:53:08PM -0400, Jon Maloy wrote: > > > > > [...] > > > > > > +/** inany_prefix_len() - Convert prefix length to native format > > > + * @addr: IPv4 or IPv6 address > > > + * @prefix_len: prefix length (any format, auto-detected) =20 > >=20 > > If it's pertaining to an inany, it should always be IPv6 format. > > Auto-detecting just masks bugs elsewhere. > >=20 > > > + * > > > + * Return: prefix length in native format (0-32 for IPv4, 0-128 for = IPv6) > > > + */ > > > +static inline int inany_prefix_len(const union inany_addr *addr, > > > + int prefix_len) > > > +{ > > > + if (inany_v4(addr) && prefix_len >=3D 96) =20 > >=20 > > Yikes. Even ignoring the fact I don't like this function at all >=20 > Can you then please suggest / sketch another solution? We went back and > forth on this topic quite a bit but we couldn't come up with anything > more elegant so far. Some of the back of the forth was while I was away, so I've not actually grasped the argument for this function's existence. You've asserted that there are cases where it makes sense, but I haven't yet seen them. I'm a bit baffled as to how that can be, because a prefix length is not a meaningful quantity on its own - it only makes sense as part of a prefix - i.e. it is always attached to an address. So, the format of that address should also dictate the format of that length: 0..32 for an in_addr, 0..128 for an in6_addr. I'm arguing that it should also always be 0..128 for an inany_addr, regardless of its value, since an inany_addr is at least sometimes interchangeable with an in6_addr, but not with an in_addr. That is, I think the length format should always be determined by the corresponding address's C type, not it's value (including it's "type" in the network sense). There might be some advantages to making the association explicit: that is defining in4_prefix, in6_prefix and inany_prefix types. But that might also have some awkwardness (those will have odd length leading to poor array packing, for example). So I'm also ok with the link between the address and length in a prefix being implicit. So, I guess the concrete suggestion I have (which I thought I made in an earlier round) is an inany_prefix_v4() function - a variant on inany_v4() which converts both the address and length simultaneously into v4 format, or fails if the input is not IPv4. > > this > > isn't good. If we somehow get a IPv4-mapped inany with a prefix_len > > that's < 96, something has already gone wrong. This, however, will > > just fall back to the IPv6 case. So if prefix_len is 33..96 it will > > return something entirely nonsensical, and if it's 0..32 it will > > return something that looks ok, but ignores the fact that something is > > already wrong. > >=20 > > > + return prefix_len - 96; > > > + > > > + return prefix_len; > > > +} > > > + > > > +/** inany_prefix_len6() - Convert prefix length to generic format > > > + * @addr: IPv4 or IPv6 address > > > + * @prefix_len: prefix length (any format, auto-detected) > > > + * > > > + * Return: prefix length in generic format (96-128 for IPv4, 0-128 f= or IPv6) > > > + */ > > > +static inline int inany_prefix_len6(const union inany_addr *addr, > > > + int prefix_len) =20 > >=20 > > This function should not be necessary. If the prefix_len is attached > > to an inany, it should already be in IPv6 format. > >=20 > > > +{ > > > + if (inany_v4(addr) && prefix_len && prefix_len <=3D 32) > > > + return prefix_len + 96; =20 > >=20 > > Similar comments here. Also a 0.0.0.0/0 is a valid prefix which > > should be translated to ::ffff:0:0/96, not to ::ffff:0:0/0 as this > > function will. > >=20 > > > [...] >=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 --qkmk0QyV0frfHT8R Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmoUF+QACgkQzQJF27ox 2GdQzhAAnZcICPzI6J4JqRIG/xqpFWNtgR6GvF0zfZQiUXgArTgFQMbgDKwfKFkY T56LI0Pru66PmCo66+dmJz0uA7K7ZZTtmum3WKGIHA+QqSZ1EpG7V1Y+cEutKoMC 0y2GlOYe++mvImPrgpTWzWuUgd4R68YNeDDAR8z7FeiDGzl0JrAO8AQfPn/C2+n5 zLp+MFFpH8GGCGx2zmko0Tly118wmw/TLZeyNlun5cR6zunFgVEvEbcEYe6IIBfJ kZ+kGpBvk/Y8Z+w4j1Uiw/+PvLglMPuhW6VqIXIY04kzBQ54Ia+fQGo4Qcp9PYkc 8pUSoaZ8ud2FddIFOBsCswnkEKNRaV9wHsO1S8rVlHOPHX7jBclVV53xfCW1tW80 Z8w8zhh0DSzQ5FfcLXtmkVmpPhaAbiiVLys+I/OGw69qsIVRdDn6llsFs9x8Mv51 oKXyPGcXS7CN1IYFoyghUY+U5ai5ree6/iwUkuoC5prcIDeru0PatdnzyjmIzVAo rq1DWhMV1QH4EmYBjQTcXf+xy1f738WLePjB3mFbo5y5uBeH76gG4kTSI6rHq06M tK0qChKO1ooBGJIWK956HqGaQ3wqVUwVNICh+OzK/WyUB4zyk3FN2oaEdsbhuasl 0h7YYIC0xbXphvwXzr1+LcRcpyitgOgSnOywrkT46FS+Az321rc= =nsY3 -----END PGP SIGNATURE----- --qkmk0QyV0frfHT8R--