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=LTTLn7uK; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id 534EB5A0265 for ; Fri, 03 Apr 2026 08:36:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202602; t=1775198206; bh=NeaAt+zO9/PtxrggmegMuniX4Vme1uTlYGK59+tfjiA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LTTLn7uKNb9ym94rQn1jpO/dajydiuvFgIKQl5UyYDKjOn8tmMacmvg/BO1KNaPga H5RMyRJdMuMtPsCzX/QT+kOEJPyYDShYvxzy6DLqOqjwUz+pvVxnBgDq+z5mXth6OQ H6/zys5ZGIqtmhjyB41Ix6cgAkQCztnUK8V6+dDNhuUpZ7+AlsSjPA6sgjCyLxYGH0 4IBmCU+fQ4svJMuxJZU4bOrnLoFbePPG6BtgyAgx3kcuFoS2T0pdEVgNhk49OkafEw GLIWBGpltbLE3fd3iYOddqpn3CyvQlrqJ+qLmb7Mxesy5X764pm+ahc6BIMhxh46jm 43sb1PlDyPOfg== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4fn8C24qksz4wSR; Fri, 03 Apr 2026 17:36:46 +1100 (AEDT) Date: Fri, 3 Apr 2026 17:36:40 +1100 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH v6 02/13] ip: Introduce unified multi-address data structures Message-ID: References: <20260322004333.365713-1-jmaloy@redhat.com> <20260322004333.365713-3-jmaloy@redhat.com> <20260330235710.3b0570fe@elisabeth> <20260403082011.13f3d51f@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qTVJqw4bA8mjYGBi" Content-Disposition: inline In-Reply-To: <20260403082011.13f3d51f@elisabeth> Message-ID-Hash: 7FDEAHFXRS62BA4LHJGWF5FNYBPJ52TA X-Message-ID-Hash: 7FDEAHFXRS62BA4LHJGWF5FNYBPJ52TA 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: --qTVJqw4bA8mjYGBi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 03, 2026 at 08:20:12AM +0200, Stefano Brivio wrote: > On Fri, 3 Apr 2026 12:25:44 +1100 > David Gibson wrote: >=20 > > On Mon, Mar 30, 2026 at 11:57:10PM +0200, Stefano Brivio wrote: > > > On Sat, 21 Mar 2026 20:43:22 -0400 > > > Jon Maloy wrote: > > > =20 > > > > As preparation for supporting multiple addresses per interface, > > > > we replace the single addr/prefix_len fields with an array. The > > > > array consists of a new struct inany_addr_entry containing an > > > > address and prefix length, both in inany_addr format. > > > >=20 > > > > Despite some code refactoring, there are only two real functional > > > > changes: > > > > - The indicated IPv6 prefix length is now properly stored, instead > > > > of being ignored and overridden with the hardcoded value 64, as > > > > as has been the case until now. > > > > - Since even IPv4 addresses now are stored in IPv6 format, we > > > > also store the corresponding prefix length in that format, > > > > i.e. using the range [96,128] instead of [0,32]. > > > >=20 > > > > Signed-off-by: Jon Maloy > > > >=20 > > > > --- > > > > v2: -Using inany_addr instead of protocol specific addresses as > > > > entry address field. > > > >=20 > > > > v3: -Merging into one array, directly in struct ctx > > > > -Changed prefix_len and flags fields in struct inany_addr_entry > > > > to uint8_t, since that makes the struct directly migratable > > > >=20 > > > > v4: -Updated according to changes in previous commits > > > > -Updated according to feedback from David G. > > > > -Squashed IP4_MASK macro commit into this one > > > >=20 > > > > v6: -Renamed and moved some definitions > > > > -Introduced fwd_set_addr() and fwd_get_addr() already in this c= ommit > > > > -Eliminated first_v4/v6() functions, replaced with fwd_get_addr= () > > > > -Some other changes as suggested by David G. > > > > -I kept the flag CONF_ADDR_LINKLOCAL, since it will be > > > > needed later in an address selection function. =20 > >=20 > > [snip] > > > > - if (!ip4->prefix_len) { > > > > - in_addr_t addr =3D ntohl(ip4->addr.s_addr); > > > > - if (IN_CLASSA(addr)) > > > > - ip4->prefix_len =3D (32 - IN_CLASSA_NSHIFT); > > > > - else if (IN_CLASSB(addr)) > > > > - ip4->prefix_len =3D (32 - IN_CLASSB_NSHIFT); > > > > - else if (IN_CLASSC(addr)) > > > > - ip4->prefix_len =3D (32 - IN_CLASSC_NSHIFT); > > > > - else > > > > - ip4->prefix_len =3D 32; > > > > + fwd_set_addr(c, &inany_from_v4(addr), CONF_ADDR_HOST, > > > > + prefix_len + 96); =20 > > >=20 > > > Somewhat symmetric to David's comment to inany_prefix_len(): > > > fwd_set_addr() is already checking if the address is IPv4 or IPv6, so > > > you could pass the actual prefix length. =20 > >=20 > > I disagree - in fact I suspect the + 96 is there because of my earlier > > feedback. When a prefix length is associated with an inany, it should > > always be encoded as for an IPv6 address, since an inany essentialy is > > an IPv6 address. There are cases where we can directly use an inany > > as an IPv6 address, without caring that it might be (dual stack socket > > interfaces). If we need a prefix length in that context, we need to > > be able to treat it as an IPv6 prefix length, without having to adjust > > it for the case of a v4-mapped address. > >=20 > > The +96 here is representing that we're converting from a strictly > > IPv4 addr+prefix_len to an inany addr+prefix_len. >=20 > Hmm, I see. I considered the prefix length argument in this case a > separate bit of information compared to the inany stuff, nothing > else than a "prefix length" argument. But I see why you might consider > that strictly in conjunction with the inany argument. I mean, fwd_set_addr() is essentially storing a addr+prefix_len as a prefix in the table, so I think it's reasonable to consider the passed address and length to be linked. > > > Having to add 96 for IPv4 looks rather bug-prone for the future. =20 > >=20 > > It definitely has gotchas, but I think the ones we get by > > inconsistently encoding the prefix length for an inany are worse. > >=20 > > I do think the gotches here could be significantly mitigated by having > > variants of inany_v4(), inany_from_v4() and the like which convert an > > entire prefix (i.e. address and prefix length in the same call). >=20 > Ah, yes, that would definitely help. I'm not sure how complicated it > is. Maybe we could as a start have a INANY_PREFIX_LEN_FROM_IPV4(x) > macro or something. But I'd say let's leave + 96 here for the moment if > we risk adding more interruptions / complexity. I think it's not too bad to (conditionally) get an IPv4+prefix_len =66rom an inany+prefix_len. The other way is more awkward, but also less common. As noted, having explicit types representing prefixes would probably help. --=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 --qTVJqw4bA8mjYGBi Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmnPX/MACgkQzQJF27ox 2GfwVhAAiuw/e2paxGamkSfcNhU/vl3nvYELk4bl9hPfUNA8PSRuaxnEj830v/Qo uFfHkPegtdWM7RlJwJgaKS8di/KzvdL44K94MMSYZtVXKSpT2iicxNxsr8odTKcl vBGigShSLL34qSSo336L4qNtawSYHd8bJcsGHYCbRRFvYGjjiCSRktkEn+I4XsOj 9hA6+r7vEZhrf+HHp1ubOi8AMlEO0I6CXfJV/8HMUzwftlzNSUFVsskMUo7d/npU SY5MumJJkqEP+oirfkUlIgfB5PsM7O9+maSHjMz0fUrcfoAZSJObLsPQRGGldp87 yKRW8YS55rkCTBpsDVqG3iVw+t8Z4PeTO9lsMT7jGrVXcd4aLQNgMRVqEQqnrTjl pliNbF4Pvdxsf0t4Q+DYcy9O7Mf8a6ObrPnNid+WJj5Cu36nojM/dQrTprOixSt0 C2LI8OUv+p8eFntOL7iXDW42D851tU+HLX7NUYkr/vS3+3KBXVAcTgJokYR9hy/1 +lG13rKavsb5jE+vtuQW1g97gb2iQta369+Zodz4cWnemg+aDPY6Vpoj/dvw8SrK 5it7A73cM5qxFp6KKhKdjaYAvAdmEIIV/nPmxKv2bV6f+v+sljoy4rfF0pYgqfYT Z7T0QkXoC1wZFqw+lJHg+m++efSxNK/yWuATc6lMYfLC5wnScPs= =P+4i -----END PGP SIGNATURE----- --qTVJqw4bA8mjYGBi--