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=LrnB2kFT; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 0C7475A0265 for ; Mon, 29 Jun 2026 21:47:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782762422; 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=Vgz+O8r7Nfz6Hd7rUGpwv3HbcweFCOjNCexaWZQQXY8=; b=LrnB2kFTjrrhZzK4/j0ZDUKKOkZj0ymsUkLmj680xKcPOv34M9yzYm5pHALi1wAoZ+xf1j OigZ2o0EPqOp+N0KyxEo9UJ0c9bgjTcRKITwA/koaoRcFS6FVcoRL99wlGFKrJLkEY8gVY 5cMlc/dYl4T/C9KHEPBF8wp0KUK0n8g= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-639-yVa7fNSjN26uJ-3ga70ktQ-1; Mon, 29 Jun 2026 15:47:00 -0400 X-MC-Unique: yVa7fNSjN26uJ-3ga70ktQ-1 X-Mimecast-MFC-AGG-ID: yVa7fNSjN26uJ-3ga70ktQ_1782762419 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-490a767b782so28635805e9.2 for ; Mon, 29 Jun 2026 12:47:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782762419; x=1783367219; 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=Vgz+O8r7Nfz6Hd7rUGpwv3HbcweFCOjNCexaWZQQXY8=; b=UYaSSp64HiyMQk0hrlnkl2ned8kiuA0c9mpO2PTbGDO9AElMpiUOy7F/Mdz7xrMs0L YDr9QbgWmQp6U1c4hajTbsNVOeffF9N7a8ocYtTf1r1QCw8LX2kmrNBD9F+NDJHGbTmJ wlh2E4qq5DSBbdJP7KkWBuqCbpJ5S8WJlqDFY9u2h0rEQz4OKe0k41BHsiMn5f7d1rQn F3yrzoH6dn25ymRQtXab7c4a7W7WiKmzle6vaVUyLsdk+l2aaQLEEE2aUXxaBkBe4Iog F0b+3fHr4Lm3oBcyoVEU+UX4GAkqi9+67qGGfaUqcFvoGYZzQUTSvcRzLji1D49NIhKg d8YQ== X-Forwarded-Encrypted: i=1; AFNElJ/nrO5oFj0ocaTlKpFma9PjUY8ozY5gg8lDQg7PD30WKtcEZWiMpmtSbQYsk0VYsJnPXjaSsPHK+QA=@passt.top X-Gm-Message-State: AOJu0Ywwf+zyHez5nk2pcEUQl/zEPVmJNbN9vAp+Kq6LmHIHKOXPnIpg 2cuPyu3SStMrdCiB5oTQvHKqzTY42NvPtrzewgF7FzTFcR3nzydjYv2Cxf1Og3v32wr9maaWXkC JSWkqc1dyPx3cW/089mwnYVoFINa2F/iX2h+ObywvbPkuWBLfgJo/aw== X-Gm-Gg: AfdE7cnyU/IgNsUSWn501+jPTm9n2oRQlJpuM5RuZukJEm94gwOwD2NIUg1WVRYyZfC nP5PuLtEStkhNx4PJ2ZLHnS0Zg6beP2kTultjV5JuU1OeKJLJIEeF5nnUrbJuUhKU4NVXDQvFRK Dqob4G8SzWX+8Prynt3r6MZuubJtnPBWPW938hDVsgGmjdL881ZOrRJkiimBDDDnhtAKOfdao/z hW6TE1NEgjFBfLiMOu3iwo+sqb4DAyjLYZBIWRpd304QfFSuwZdjpOjAfMxxMc1Cwc3LOIZSLel 3n33zLFJfVXBtc/Fr2RuQbiv5xYqv5bxmPQW8rBO6Npt/2Ujn/7ckyaw1f4oA1FcFY0387B32Wb i9bVuBK1KTr3fM7wD9tRgkg== X-Received: by 2002:a05:600c:3485:b0:492:1e36:1fe9 with SMTP id 5b1f17b1804b1-493b82c654emr13940145e9.37.1782762418939; Mon, 29 Jun 2026 12:46:58 -0700 (PDT) X-Received: by 2002:a05:600c:3485:b0:492:1e36:1fe9 with SMTP id 5b1f17b1804b1-493b82c654emr13939925e9.37.1782762418357; Mon, 29 Jun 2026 12:46:58 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-493b8c721f3sm15389045e9.5.2026.06.29.12.46.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jun 2026 12:46:57 -0700 (PDT) From: Stefano Brivio To: David Gibson Subject: Re: [PATCH v7 02/13] passt, pasta: Introduce unified multi-address data structures Message-ID: <20260629214656.1bfb76c6@elisabeth> In-Reply-To: References: <20260413005319.3295910-1-jmaloy@redhat.com> <20260413005319.3295910-3-jmaloy@redhat.com> <20260620000951.09b50452@elisabeth> <20260625005652.569401b4@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: Mon, 29 Jun 2026 21:46:57 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: OC1f8LjeeDiXfWmn9HCO6EJ4poW_-rohjoWugvZhl3I_1782762419 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: ALMR443AHUW4OLZIUZ3ER7I6JE4CNIDD X-Message-ID-Hash: ALMR443AHUW4OLZIUZ3ER7I6JE4CNIDD 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, 29 Jun 2026 18:23:21 +1000 David Gibson wrote: > >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: > > > > > 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. > > 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. But the reason behind it is the same: guests without a DHCP client, so I don't think it's more or less perverse in its intention. > 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. Hmm, what precludes what exactly? That actually seems to work with pasta, people tried "device routes" with Wireguard successfully if I recall correctly. > > 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