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=UK9hgfD7; 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 9CF675A0265 for ; Fri, 03 Apr 2026 08:20:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1775197223; 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=aDqdJbw0CRTUVeGDhxogevj7kU3jZuklefZD98a0p6c=; b=UK9hgfD7vHmGJuYiK4suoo40hnW7cBrapsp67QdDXxaHTj551ISWdpdMx7vywu4jPd9C2q OuDYDh98YN6QYtAHKq1eStLMSsVYvabrxgAUGj2+tlRLRaFa01yqvvyrZIxLbqWowziqn7 P36is++wmIgFWbkP6K3BlyKxTQFu/4c= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-387-im03tLFUNU6-4RaHcpmBkw-1; Fri, 03 Apr 2026 02:20:20 -0400 X-MC-Unique: im03tLFUNU6-4RaHcpmBkw-1 X-Mimecast-MFC-AGG-ID: im03tLFUNU6-4RaHcpmBkw_1775197219 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-43b96365ea8so1784835f8f.2 for ; Thu, 02 Apr 2026 23:20:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775197219; x=1775802019; 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=aDqdJbw0CRTUVeGDhxogevj7kU3jZuklefZD98a0p6c=; b=FTcYoRsGo/4AYHuEVq9VcyYkJjEasVRForh9Zxi27rxw0U+Si3FJsoBI9W7HDLT0wU H/jub31FpwY9nyBtcL4SkyxuqeNXhZV0a4URXbOCGEWuTmyYAr9dzYKkgwuEzj5I1Gr0 WzowzoroMD/GcBr5mn0Bz9RWokKX/xfTMrgugy8HNwViMiVOo1ikiJOb3RZAzYUP3icZ rKGv9vAlBYLInI1i1UT3N35wDY3rHku60fn4mIr+KkQHqJif/md7kDG/Czli5Lk8Uapy N/2jkmznOEzn8FrbpufFiPJt2J2UBpl4mNnysk4JcFrqydaSqlRX4bV/3/mDkYB2EirP PVBA== X-Forwarded-Encrypted: i=1; AJvYcCVW4OILHDfnozLqxyTmp7pjOWFmNbJ6rJeJYYBXUiEK38zB5xWIMRDmsHHihDulrYb2XDHa6cgDLrE=@passt.top X-Gm-Message-State: AOJu0YyfR/+Oc1R8q2vRz2+SI5SHL1mG7B/pu0hTGvF9PbgVl/C1Jlgk OyrkdCCkaHs9dLtFuxyaSMfr8vyi4ctSDLwsO8C7RW2RksHrosgVsP8pVtsc4c1WvytdcdNFnVm cCBWtjQjUGoYc/i4gLuAdaFg1tRpHIaB9teMgavY/fHvOBF7d/iu1EQ== X-Gm-Gg: AeBDieuVQ4DSe4bvvTybdsgOO4cQ/U2lmN3zczhjkKkThbhg5aBMdwIcP0vf8cuh8SE 3XVbs7/AvR3YPk28mQ6u7X8BE5oBEqKhcofYL3DSz5Hb034DBDMysptXPX5A4BMEQjWA98kp5zk pY8HdVEWGiNhEmh8ORWst+xRnSfDaz7BzIHXajtyzpe/r9WAPMlQZJspGDr3RB3HXJTEWtSxUF+ teM5APU9g3i2zu1x//SkQVBJyeWXKpkZ4LHsqXQdlQsf53jlduy/hA7nsrecQC33eBNW6XQKyjm qeL66sR6z7U3Oq6WlxaFnJ8/fmd0cPaRYM4Yx3Q25Wq+dS0tsmcRoIdhz5BNx/5ShQSxDzgbEyt 2E91NSlXEXEq2zIxUEYcu94am4hQ5GBv0 X-Received: by 2002:a05:6000:1789:b0:43c:f969:2e1 with SMTP id ffacd0b85a97d-43d29276481mr2698794f8f.6.1775197214493; Thu, 02 Apr 2026 23:20:14 -0700 (PDT) X-Received: by 2002:a05:6000:1789:b0:43c:f969:2e1 with SMTP id ffacd0b85a97d-43d29276481mr2698726f8f.6.1775197213699; Thu, 02 Apr 2026 23:20:13 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43d1e2c637asm13058473f8f.14.2026.04.02.23.20.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Apr 2026 23:20:13 -0700 (PDT) From: Stefano Brivio To: David Gibson Subject: Re: [PATCH v6 02/13] ip: Introduce unified multi-address data structures Message-ID: <20260403082011.13f3d51f@elisabeth> In-Reply-To: References: <20260322004333.365713-1-jmaloy@redhat.com> <20260322004333.365713-3-jmaloy@redhat.com> <20260330235710.3b0570fe@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: Fri, 03 Apr 2026 08:20:12 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: h6VwSEh1a6vYzkLVjuhjpLQTh4iMSeRivhXIfr4jW2I_1775197219 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: MUUGPGV3BZYLTYL2U63SZBXECNC57S5Z X-Message-ID-Hash: MUUGPGV3BZYLTYL2U63SZBXECNC57S5Z 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 Fri, 3 Apr 2026 12:25:44 +1100 David Gibson wrote: > 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: > > > > > 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 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]. > > > > > > 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. > > [snip] > > > - if (!ip4->prefix_len) { > > > - in_addr_t addr = ntohl(ip4->addr.s_addr); > > > - if (IN_CLASSA(addr)) > > > - ip4->prefix_len = (32 - IN_CLASSA_NSHIFT); > > > - else if (IN_CLASSB(addr)) > > > - ip4->prefix_len = (32 - IN_CLASSB_NSHIFT); > > > - else if (IN_CLASSC(addr)) > > > - ip4->prefix_len = (32 - IN_CLASSC_NSHIFT); > > > - else > > > - ip4->prefix_len = 32; > > > + fwd_set_addr(c, &inany_from_v4(addr), CONF_ADDR_HOST, > > > + prefix_len + 96); > > > > 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. Hmm, I see. I considered the prefix length argument in this case a separate bit of information compared to the inany stuff, nothing else than a "prefix length" argument. But I see why you might consider that strictly in conjunction with the inany argument. > > 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). Ah, yes, that would definitely help. I'm not sure how complicated it is. Maybe we could as a start have a INANY_PREFIX_LEN_FROM_IPV4(x) macro or something. But I'd say let's leave + 96 here for the moment if we risk adding more interruptions / complexity. > [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; > > > > 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. Right, I realised later when I reached 9/13. > [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] format > > > > ...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. -- Stefano