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=O9HhGdtP; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 1FD255A0262 for ; Fri, 03 Apr 2026 03:26:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202602; t=1775179563; bh=wo4ZMAGE/WIg+FfQmRaRI1IOsSwnoXs7nQzhJwC4mnM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=O9HhGdtPyKX+DqXSgW1HLXRjW8WhJ3pm9+E6dXcWuCAdtukkO4RRqRg2rQWhyF/2S DXlHwAy5ybWi9lxSDbw2yw+ZeXdmI6fsR9eQSzwdfBKKl+GnVGMbShPCFMViRAc/qz iv8pdchKgeCXrgZmv1H83njlaDzyvEECdbQbp4JXg2+tHWtiLhhc9kO5pZmDMbnSli c8jNIY2Z6IYudo/3Jk2Or3SWzoY96m58o8tSccQDQhKwebmdYV3WCsw2zmKIw3RkAc 6Jq9iWOzmX86cTW9JI+f3eEInWD5alYswWtZy4eArUEXjNleHkTnL6183Hpk4vZ0yM rJ2CuQkf/QPCA== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4fn1JW57bYz4wSy; Fri, 03 Apr 2026 12:26:03 +1100 (AEDT) Date: Fri, 3 Apr 2026 12:25:44 +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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pvBAMvi7uPw0I7bA" Content-Disposition: inline In-Reply-To: <20260330235710.3b0570fe@elisabeth> Message-ID-Hash: NIMMUX5L5R4IYX7DV7RT5ZVFMKL2TM5R X-Message-ID-Hash: NIMMUX5L5R4IYX7DV7RT5ZVFMKL2TM5R 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: --pvBAMvi7uPw0I7bA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 commit > > -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. [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 > 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. 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. The +96 here is representing that we're converting from a strictly IPv4 addr+prefix_len to an inany addr+prefix_len. > Having to add 96 for IPv4 looks rather bug-prone for the future. It definitely has gotchas, but I think the ones we get by inconsistently encoding the prefix length for an inany are worse. 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). [snip] > > +/** > > + * fwd_get_addr() - Get guest address entry matching criteria > > + * @c: Execution context > > + * @af: Address family (AF_INET, AF_INET6, or 0 for any) > > + * @incl: Flags that must be present (any-match) > > + * @excl: Flags that must not be present > > + * > > + * Return: first address entry matching criteria, or NULL > > + */ > > +const struct guest_addr *fwd_get_addr(const struct ctx *c, sa_family_t= af, > > + uint8_t incl, uint8_t excl) > > +{ > > + const struct guest_addr *a; > > + > > + for_each_addr(a, c, af) { > > + if (incl && !(a->flags & incl)) > > + continue; > > + if (a->flags & excl) > > + continue; >=20 > Slightly less generic, but maybe good enough for this purpose: you > could admit a set of flags, or a negation of a flag (for example > ~CONF_ADDR_USER), in a single argument. I don't think that will work, because we almost immediately have callers that need both an included and excluded flag. [snip] > > + > > +/** > > + * struct guest_addr - Unified IPv4/IPv6 address entry > > + * @addr: IPv4 (as mapped) or IPv6 address > > + * @prefix_len: Prefix length in IPv6/IPv4-mapped [0,128]/[96,128] for= mat >=20 > ...do we want to introduce a separate type for inany_addr plus prefix > length? I'm not sure. Yeah, I've been wondering that too. It would make some of those encoding conversions more elegant. --=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 --pvBAMvi7uPw0I7bA Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmnPFw4ACgkQzQJF27ox 2Gfeww//f+OqFql9SXh9OClhRloAUL5D2QctYCjyJABcctHpKc/XDFFmtzM+/xdH rIGlqJ+h5PZTowTGRTEJXvRgf/idgxFTDzyPlP9o+WvbiC4WsDbUdkmG3OoeSAd1 dzGHXu7Vhw+2VZ+4jl+6AMFI6/TKQiomslEoM1Uo0r/Ia4Iab422VgulRIGsQdwm BVT9+bIdloVTf6RLSxlhklyAECAYig4LQhWaH5RuQ87/i2mI5kJdspbrYuuV79x1 EGOFtyykUEr4frGikamsR/mecZp9/Ybr1t29c5MJhHYmkJwNFMRrH6wHUORCaZji uhda121qboeTXne2UnF5HymdR8hwoJzxE/TJyNw4EctJX/bpjVVeW8Y1h/orKOGc L1vSYFHgW2l7bzWkBryen2kOA4b04hZr7mAjdgEtXng0riQ7pNl2IOK+/GLvxuQE 2jMX+ibZ2WxfnqYSNLjc6XfZzLoVa62pFgr5EhQD7ziFYLAzGmQE+6UDReBEXlLs keP53zdwfgPkyDUeiBYbVuAHYXtlRavgwUnUScg6NbqGanTFezC50+yfUwLS+55c +b1e+Z/p2HePXCMYZZgw9zFGjAYKwYUoharzJljS0uxYIT/TlhVW1JLwKA3rzPoN 5q+afNT+7n94M32pvfcvTsLmkqvHCLmbxDCVrPCnXkm/zgjaqyk= =Ohpn -----END PGP SIGNATURE----- --pvBAMvi7uPw0I7bA--