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=202606 header.b=e0h+4KC/; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id 882DD5A0265 for ; Thu, 09 Jul 2026 07:59:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202606; t=1783576781; bh=569foNyh8I67hbg+L6iO63WnWasWNbxbUdYRwirHJvU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=e0h+4KC/MQ2BNMxBVyK0Q4GjLZ0HYLToJTKyxPQBHGrYrmcrOV/rBjdkxzWsMTi/D rqU8HDyA5/xOWroaKGemg+agTo1YV8/1qF5eEm8KQwLcO8U8AjeHk4IAcmDas/xV3k OseijmQeoQrcvmKrEHdgKBvDCtIv05i3x6k2kMmptk4mtSINVr/91EXlYcTUUjO81D VyeWZYHFuow3Hb0hRAB8oPZj4NiCfKC8jACzg21YiEigEQaX49n0qTM6nc9gzUDFqe K7lAEQJeCcjzrefzv4EdRGwHABnBlRwXfjgWDkDvxLxgZfvge2oAdbNE4gJrzy1hfj 2D/WDID/auJHA== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4gwknT0gZ5z58dS; Thu, 09 Jul 2026 15:59:41 +1000 (AEST) Date: Thu, 9 Jul 2026 15:59:32 +1000 From: David Gibson To: Jon Maloy Subject: Re: [PATCH v8 02/14] passt, pasta: Introduce unified multi-address data structures Message-ID: References: <20260626024519.3701556-1-jmaloy@redhat.com> <20260626024519.3701556-3-jmaloy@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="O7GMMKr8KeUtkISU" Content-Disposition: inline In-Reply-To: Message-ID-Hash: WXQGYPBMUISN2UDCKW3GB3GEB7H4LXCS X-Message-ID-Hash: WXQGYPBMUISN2UDCKW3GB3GEB7H4LXCS 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: sbrivio@redhat.com, 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: --O7GMMKr8KeUtkISU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 09, 2026 at 03:56:08PM +1000, David Gibson wrote: > On Thu, Jul 09, 2026 at 02:05:11PM +1000, David Gibson wrote: > > On Thu, Jun 25, 2026 at 10:45:07PM -0400, Jon Maloy wrote: > > > 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 > > > 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 > > > In conf_ip6(), the explicit IN6_IS_ADDR_UNSPECIFIED() check on the > > > address at the end of the function is no longer needed: for > > > host-discovered addresses, it is now checked inside the if (!a) block > > > before calling fwd_set_addr(); for user-provided addresses (via -a), > > > validation already rejects unspecified addresses at parse time. >=20 > Following up with a more general observation. We've now been through > a bunch of iterations with various problems in the filtering logic of > fwd_get_addr(). On reflection I think the whole idea of a single > "get" function with a couple of mask parameters is flawed. The > conditions we want to filter on are more complex than this, because we > do have both different provenances of address and types of address. >=20 > The major use of fwd_get_addr() in these early patches is to replace > direct references to c->ip4.addr, c->ip6.addr or c->ip6.addr_ll. In > later patches, many of these go away, because you instead iterate > through and do something for *all* relevant addresses. So, I'd > suggest instead of trying to make this general-but-actually-it's-not > lookup function you instead insert 3 specific functions: one that > retreives an ip4.addr equivalent address, one an ip6.addr equivalent > and so forth. >=20 > That removes the evidently confusing filtering logic of fwd_get_addr() > and makes for smaller and clearer changes in the many places that need > to be changed to use the new data structure. Through the rest of the > patches callers of those will mostly go away, and they can be removed > again. Oh, and finally. I'm not going to review the rest of this series. I think we need to get the basics of the data structure right, in this early patch before it's worthwhile having another long revise/review cycle on the rest. --=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 --O7GMMKr8KeUtkISU Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmpPOLYACgkQzQJF27ox 2Gf33xAArMskrj/JX8++hT7ICy8qmmsCVslW/NU4KY4QtQ9UP8s+5KIUXrEMlmb7 rg+sz9VLwzz8zae6kCoPmapuhnLYBSfWYvWX93O7TjJB7EOjDubLLwIkE9YPRqtx XiFcNQfVuNTPZ4ggUWwUUEEHtQp3XL/bscr0K4cpG3R0AAZj/ZFBZiCW8oXEM70r 7gmXlrV+OLD7qtD2Nj1+Pdpl42bKbYRLO62mhNHKli86FcF03Dic125bCgrZty5b DGaA8aac3sVS4hqANQx1yP3SoX1tkjOPciKHpQDHWDNSqS5zCb7SOxQW0nqTa/Ui VSQWVgU+HKU65+YNpmZzg5v/d1UX8+LxijYD2N3KzCAZq0XmuxtcAyPjNkO8lyd8 6XQTCMiF8mkPH9rcnJnLRAMb7+FCWcfgR3hF1YVjoImSeK8De/H/S+Y16JuKuxOS cuTsJWsya+GB4ylTFVIrS4QqMABU1aszjmE8mOu5V+lCJ0TkLFy0uh0eYMSAhgBp w8/R/G1HqRi4QuJUut3U3RdwdXn3nag3qrVqCH6uGVusof7PWpi+uNNNTI+piPN9 5g1LiFVcEhHN3QEEnyb1WY8ZhGSXtfm/KG9CysieMLb5qsnSIctsrLT0cqY0tSLe JTUPUiE1bJD7CUJg/sStVUvJVgORxcKRBQt11YSXd1t1/kIV7rU= =SKPP -----END PGP SIGNATURE----- --O7GMMKr8KeUtkISU--