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=T96YVO4x; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 4405E5A0269 for ; Mon, 29 Jun 2026 11:01:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202606; t=1782723680; bh=QfKf20jiL0/zV7uE8cjUS+8pRx36PxVslMtr+zXcmW8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=T96YVO4xf0PGKi4eA1mZWEiZ+Y0OCBQqhbxn9Bv1VsvMUQ02dKJTbthnM87eiZZXj XAK4pgmU744m/ObsYeIlLna5t476cmmMy7hMVYMRsGas9r/Rx+CWPpUJLgWcgCk5Wk QHB9JJcXXR1oXI4CceeTHG2M7Ll52TSPPd4wmqbvAryNPtwhKyeR+On4l1I7GBzhOf zK8+Thl9ter0m3dyBUb9iXfV0Dt0cyE7eiXYRBJnSb1hfGvpkjz795S6xur9aQ3isM H4O4UgjpAWqcKEaVrve5Ah+I60ZZOQejTcJUze2JksFhOg3/uhEjK9YnrN6dzaqMoT sDc2twr+KV/zA== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4gpgHh5MnVz4w2B; Mon, 29 Jun 2026 19:01:20 +1000 (AEST) Date: Mon, 29 Jun 2026 18:23:21 +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> <20260620000951.09b50452@elisabeth> <20260625005652.569401b4@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vmS18qIIwKCD5tWX" Content-Disposition: inline In-Reply-To: <20260625005652.569401b4@elisabeth> Message-ID-Hash: 2QZQ6VPZJT5ECCKVRHYQOV5HQ3QHYFIG X-Message-ID-Hash: 2QZQ6VPZJT5ECCKVRHYQOV5HQ3QHYFIG 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: --vmS18qIIwKCD5tWX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable >On Thu, Jun 25, 2026 at 12:56:54AM +0200, Stefano Brivio wrote: > On Mon, 22 Jun 2026 11:39:48 +1000 > David Gibson wrote: >=20 > > On Sat, Jun 20, 2026 at 12:09:51AM +0200, Stefano Brivio wrote: > > > On Sun, 12 Apr 2026 20:53:08 -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 a lot of code refactoring, there are only two real function= al > > > > 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 > > > > 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 > > > > v7: -Introduced CONF_ADDR_GENERATED flag > > > > -Other fixes based on feedback from David and Stefano. > > > > -I changed signature of inany_prefix_len(), but I did not change > > > > its semantics, since the premise of David's comment is wrong: = the > > > > caller does *not* explicitly know he is dealing with an IPv4 a= ddress. > > > > In fact, there are examples later in this series where it may = be an > > > > IPv6 address, and the caller just trusts he gets the return va= lue in > > > > the appropriate format. > > > > -Introduced the inverse of inany_prefix_len(), called inany_pre= fix_len6() > > > > which always returns the prefix in IPv6 or mapped IPv4 format. > > > > The name of the function isn't great, but any alternative I ca= me up > > > > with became too long to be practical. > > > > --- > > > > arp.c | 12 ++++- > > > > conf.c | 143 ++++++++++++++++++++++++++++++---------------------= ---- > > > > dhcp.c | 14 ++++-- > > > > dhcpv6.c | 15 ++++-- > > > > fwd.c | 109 ++++++++++++++++++++++++++++++++++-------- > > > > fwd.h | 4 ++ > > > > inany.h | 41 ++++++++++++++++ > > > > ip.h | 2 + > > > > ndp.c | 16 +++++-- > > > > passt.h | 67 ++++++++++++++++++++++---- > > > > pasta.c | 25 ++++++---- > > > > tap.c | 7 ++- > > > > 12 files changed, 340 insertions(+), 115 deletions(-) > > > >=20 > > > > diff --git a/arp.c b/arp.c > > > > index bb042e9..a7fd82f 100644 > > > > --- a/arp.c > > > > +++ b/arp.c > > > > @@ -41,6 +41,8 @@ > > > > static bool ignore_arp(const struct ctx *c, > > > > const struct arphdr *ah, const struct arpmsg *am) > > > > { > > > > + const struct guest_addr *a; > > > > + > > > > if (ah->ar_hrd !=3D htons(ARPHRD_ETHER) || > > > > ah->ar_pro !=3D htons(ETH_P_IP) || > > > > ah->ar_hln !=3D ETH_ALEN || > > > > @@ -54,7 +56,8 @@ static bool ignore_arp(const struct ctx *c, > > > > return true; > > > > =20 > > > > /* Don't resolve the guest's assigned address, either. */ > > > > - if (!memcmp(am->tip, &c->ip4.addr, sizeof(am->tip))) > > > > + a =3D fwd_get_addr(c, AF_INET, 0, 0); =20 > > >=20 > > > I guess it's not strictly needed right now to avoid breaking things, > > > but, eventually, if we support multiple assigned / configured / > > > observed addresses for the guest, we should make sure we don't resolve > > > any of them. That is, we should eventually pass am->tip to a lookup > > > function. It might be in scope for this series but not necessarily. = =20 > >=20 > > I think one of the later patches already does that. >=20 > Ah, right, I actually realised but I then decided to keep this comment > (and forgot to update it) because this is another argument in favour of > a lookup function (which doesn't appear in the series at all). >=20 > > I do wonder if for supporting multiple guest addresses it makes sense > > at some point to switch from resolving everything _except_ a known > > guest address to only resolving addresses that passt "owns" on the > > guest link (basically the gateway address, maybe some NATs). >=20 > That will break compatibility with containers / guests that don't use > the address of the default gateway we set (anymore), assuming we set > one, or that we advertise. Well, yes. Trying to keep guests working when they don't use the network routing they're supposed to seems even more perverse to me than keeping them working when they don't use the address they're supposed to, which I've already expressed my opinion on. I guess it does preclude the option of telling the guest that the entire internet is on its subnet, no gateway needed. Odd as it seems, that might be a potentially useful option to have. > We also had some reports of users setting up a device route only > (perhaps for Wireguard, even though that would more naturally be a > point-to-point configuration). I can't find them right now but I have a > rather clear memory. If those are *not* point-to-point (just like in > those setups if I recall correctly), pasta resolving any IP address is > rather convenient. >=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 --vmS18qIIwKCD5tWX Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmpCK2sACgkQzQJF27ox 2GdxoA/+LTfMIqaSxgsxMLGF354DMho0SzvVbkIQCpjMEoo3dTWlm7Sm5W3iK37G zTYi5uT9X+5ad53us16hfycHh7bah67/BsUYQI9KNg+QiAWDG2KxgwEAbrJ8g8Q+ zMDP0UD8buQ3PlAlFIz8IcvLja4LmuUVTnQqrmqaqYZd3dDeUu3CC3Blj3suSYo5 Lk8Vf6H07Z10VliCuJH1OQyIoC7oQJPl7mFGQZoK7HKf6FtXIWVBQfAQDElCBX66 v0ZmfB/QLaQJTt54m70QjbCjktkcBLfE2cQr5H+b8uJW/DgWP3C83wYKMjQCszBX jKFlKQNcdHHVwbtQRVfXVUp6RZmlFEeuEE8J7ap0+Qtg+6/xq68L40ccvUvVvRAT eQk1PAtCzBClHavQf7k7zDqr82Aogwv8Fkv5RCaIig062ba4AO6wboJefG3ZwUeT ajKjwtu1HcLiJOPNH58EfSpYo65zQ9QFftiHupr7OwgWzURbJX6kUCpJvRh0hljZ /ZLPlVkFUzQ0TJsg3ModXXk8xeIvgfTVUuiDyaXbF11mXrzpEQ4iWf2y8CnZWX0k hUzqV3GmkwbI9nyR2Tp31sftK7/13Wa9bFsNKHrcggXLlOkVPhg2lHjMLly6WHo6 +0BQOE44P9V6c3540mOE4cnZr3gdffO+Jsi6WuLg55Ih+zJmxSk= =tbcV -----END PGP SIGNATURE----- --vmS18qIIwKCD5tWX--