From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=SJr90doE; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id 5C07E5A0262 for ; Thu, 25 Jun 2026 00:56:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782341818; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wFyLVuwDOVj/LuxL28c/ds1Lk0+3UlUV/du+sDCqB5Y=; b=SJr90doExg83P8R77w++dMWx8CwgKLYlhPxWd6GayFtFKrsg7VPhtF4LO9fVIvmrBF5Ae5 1KA34ro2ecyAjOs1bDMCwTRXu9eH/A7Sz4Y/PSluSa95JYR3fLFRKgGoZiQfZTjD3foVgG YEMDABaOG8RfF+uS5bPW3Gnip5sYBn0= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-586-Cav9uIygMluXTemcodPPwg-1; Wed, 24 Jun 2026 18:56:57 -0400 X-MC-Unique: Cav9uIygMluXTemcodPPwg-1 X-Mimecast-MFC-AGG-ID: Cav9uIygMluXTemcodPPwg_1782341816 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-490b2f22ea2so12404375e9.1 for ; Wed, 24 Jun 2026 15:56:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782341816; x=1782946616; h=date:content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=wFyLVuwDOVj/LuxL28c/ds1Lk0+3UlUV/du+sDCqB5Y=; b=ZCVtx37xv/HI2EoJGDUnyjxN4wglkMy5A+opuXNuGPQyptqe/9oKPves9vXhFijKwm x+zDf3V44UrQIjumUKHi20f9UtsW0aubvqbUw0Srsv2reUXuMR0rGwfWtwNuY4AL4uGV 2ZjBaY5nIq7L6qvpjwYi1R08i0wbNudoTBcA0YoY1u+UHRgT3QYrr++sQg1yEmTkILFB o+lJyPk21lDl9PIxuWYLDMgO4853NSPUTlzH5sQJWp4ZF0YmIvhKtrCnHhnxuxgWIIQc i0y4COyTcAnr0GDGxSmt2J8qLQ158qLQBPuX/dXps79G+39W/1An9mZsfEdiVzqPGL+W No+w== X-Forwarded-Encrypted: i=1; AFNElJ90fAEzrbtN90JVZqpmLSAww5j64kf4eTxB+H/UfKbOiwf64wIPdW3XQKg+6VJbKahDXxkBtBTpJO8=@passt.top X-Gm-Message-State: AOJu0Yy7sIlsDMqhZWbkiEgXtuQ1aSVmeg7N4D0xmA0F3/0l/QgSTw/I R0uKg907SIWm94/8mKZWqqvF8avz7l841surdLPScDL/WPah7WIuQTT05jRHjkBmFM7AAhqWZd5 vGUF4lP4rnbBaFRinq6lAeoiGdIFD+5jMDf9ZXRqmOfkqBFZClnde7qxgmCfOFQ== X-Gm-Gg: AfdE7cmaOWx5prxdksgeG7d4CfEdaC61Eu9moMOxBsJDCF1z9hCcmIs+ZflZbj1rO2/ iUya4A2x+EfWWbIpIH+OhywAsmR7Y4WTAU24Q6SQ/cr4NyeUM9nuJGF3WWKGvjSRalGH79fKH7Q dz33wNDkT2micUx3Q5Y6ChmNjsRgbGM/85EQiEBZ5sxERSZ39QIY4chhfJwdE3Iu6tV517j3Mpw dUhtX1bs9cx7aNaFYP7dDW36aqchin/a122QxeREKhXST1UMr4ZOjmnu8/AOmPeihvvxvvt8dQ0 AY2unNV9RnBWmQAl0q/OJpFXUiMWJbVSAJoVp6aZpMatcaF7WYZxrAI3lEdF+ZxY9pjLyLu7Nb5 AFfKddZ/uqYQ+70+ZOrM/b2CStk6Pe4bEE4tpVtA= X-Received: by 2002:a05:600c:c48e:b0:492:437a:a653 with SMTP id 5b1f17b1804b1-49260879449mr74657045e9.26.1782341815888; Wed, 24 Jun 2026 15:56:55 -0700 (PDT) X-Received: by 2002:a05:600c:c48e:b0:492:437a:a653 with SMTP id 5b1f17b1804b1-49260879449mr74656825e9.26.1782341815341; Wed, 24 Jun 2026 15:56:55 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-46c22c680fasm10640457f8f.34.2026.06.24.15.56.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jun 2026 15:56:54 -0700 (PDT) From: Stefano Brivio To: David Gibson Subject: Re: [PATCH v7 02/13] passt, pasta: Introduce unified multi-address data structures Message-ID: <20260625005652.569401b4@elisabeth> In-Reply-To: References: <20260413005319.3295910-1-jmaloy@redhat.com> <20260413005319.3295910-3-jmaloy@redhat.com> <20260620000951.09b50452@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Thu, 25 Jun 2026 00:56:54 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: Yg-D5aseHKuKQuViIwv1wTWhcWM6EVc7WteJ5gdVgCw_1782341816 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: KZBHN227SJIR2V6A5YXBGF32I6PIRRHI X-Message-ID-Hash: KZBHN227SJIR2V6A5YXBGF32I6PIRRHI X-MailFrom: sbrivio@redhat.com 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: On Mon, 22 Jun 2026 11:39:48 +1000 David Gibson wrote: > 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: > > > > > 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. > > > > > > Despite a lot of 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]. > > > > > > Signed-off-by: Jon Maloy > > > > > > --- > > > v2: -Using inany_addr instead of protocol specific addresses as > > > entry address field. > > > > > > 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 > > > > > > v4: -Updated according to changes in previous commits > > > -Updated according to feedback from David G. > > > -Squashed IP4_MASK macro commit into this one > > > > > > 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. > > > > > > 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 address. > > > 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 value in > > > the appropriate format. > > > -Introduced the inverse of inany_prefix_len(), called inany_prefix_len6() > > > which always returns the prefix in IPv6 or mapped IPv4 format. > > > The name of the function isn't great, but any alternative I came 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(-) > > > > > > 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 != htons(ARPHRD_ETHER) || > > > ah->ar_pro != htons(ETH_P_IP) || > > > ah->ar_hln != ETH_ALEN || > > > @@ -54,7 +56,8 @@ static bool ignore_arp(const struct ctx *c, > > > return true; > > > > > > /* Don't resolve the guest's assigned address, either. */ > > > - if (!memcmp(am->tip, &c->ip4.addr, sizeof(am->tip))) > > > + a = fwd_get_addr(c, AF_INET, 0, 0); > > > > 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. > > I think one of the later patches already does that. 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). > 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). 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. 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. -- Stefano