From: David Gibson <david@gibson.dropbear.id.au>
To: Stefano Brivio <sbrivio@redhat.com>
Cc: Jon Maloy <jmaloy@redhat.com>, passt-dev@passt.top
Subject: Re: [PATCH v7 02/13] passt, pasta: Introduce unified multi-address data structures
Date: Mon, 25 May 2026 19:35:37 +1000 [thread overview]
Message-ID: <ahQX6Q2nUO5l9dbE@zatzit> (raw)
In-Reply-To: <20260515012832.547eadb6@elisabeth>
[-- Attachment #1: Type: text/plain, Size: 4142 bytes --]
On Fri, May 15, 2026 at 01:28:33AM +0200, Stefano Brivio wrote:
> On Thu, 14 May 2026 16:30:16 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
>
> > On Sun, Apr 12, 2026 at 08:53:08PM -0400, Jon Maloy wrote:
> >
> > > [...]
> > >
> > > +/** inany_prefix_len() - Convert prefix length to native format
> > > + * @addr: IPv4 or IPv6 address
> > > + * @prefix_len: prefix length (any format, auto-detected)
> >
> > If it's pertaining to an inany, it should always be IPv6 format.
> > Auto-detecting just masks bugs elsewhere.
> >
> > > + *
> > > + * Return: prefix length in native format (0-32 for IPv4, 0-128 for IPv6)
> > > + */
> > > +static inline int inany_prefix_len(const union inany_addr *addr,
> > > + int prefix_len)
> > > +{
> > > + if (inany_v4(addr) && prefix_len >= 96)
> >
> > Yikes. Even ignoring the fact I don't like this function at all
>
> Can you then please suggest / sketch another solution? We went back and
> forth on this topic quite a bit but we couldn't come up with anything
> more elegant so far.
Some of the back of the forth was while I was away, so I've not
actually grasped the argument for this function's existence. You've
asserted that there are cases where it makes sense, but I haven't yet
seen them. I'm a bit baffled as to how that can be, because a prefix
length is not a meaningful quantity on its own - it only makes sense
as part of a prefix - i.e. it is always attached to an address. So,
the format of that address should also dictate the format of that
length: 0..32 for an in_addr, 0..128 for an in6_addr. I'm arguing
that it should also always be 0..128 for an inany_addr, regardless of
its value, since an inany_addr is at least sometimes interchangeable
with an in6_addr, but not with an in_addr. That is, I think the
length format should always be determined by the corresponding
address's C type, not it's value (including it's "type" in the network
sense).
There might be some advantages to making the association explicit:
that is defining in4_prefix, in6_prefix and inany_prefix types. But
that might also have some awkwardness (those will have odd length
leading to poor array packing, for example). So I'm also ok with
the link between the address and length in a prefix being implicit.
So, I guess the concrete suggestion I have (which I thought I made in
an earlier round) is an inany_prefix_v4() function - a variant on
inany_v4() which converts both the address and length simultaneously
into v4 format, or fails if the input is not IPv4.
> > this
> > isn't good. If we somehow get a IPv4-mapped inany with a prefix_len
> > that's < 96, something has already gone wrong. This, however, will
> > just fall back to the IPv6 case. So if prefix_len is 33..96 it will
> > return something entirely nonsensical, and if it's 0..32 it will
> > return something that looks ok, but ignores the fact that something is
> > already wrong.
> >
> > > + return prefix_len - 96;
> > > +
> > > + return prefix_len;
> > > +}
> > > +
> > > +/** inany_prefix_len6() - Convert prefix length to generic format
> > > + * @addr: IPv4 or IPv6 address
> > > + * @prefix_len: prefix length (any format, auto-detected)
> > > + *
> > > + * Return: prefix length in generic format (96-128 for IPv4, 0-128 for IPv6)
> > > + */
> > > +static inline int inany_prefix_len6(const union inany_addr *addr,
> > > + int prefix_len)
> >
> > This function should not be necessary. If the prefix_len is attached
> > to an inany, it should already be in IPv6 format.
> >
> > > +{
> > > + if (inany_v4(addr) && prefix_len && prefix_len <= 32)
> > > + return prefix_len + 96;
> >
> > Similar comments here. Also a 0.0.0.0/0 is a valid prefix which
> > should be translated to ::ffff:0:0/96, not to ::ffff:0:0/0 as this
> > function will.
> >
> > > [...]
>
> --
> Stefano
>
--
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-05-25 9:38 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-13 0:53 [PATCH v7 00/13] Introduce multiple addresses and late binding Jon Maloy
2026-04-13 0:53 ` [PATCH v7 01/13] dhcpv6: Fix reply destination to match client's source address Jon Maloy
2026-05-14 5:21 ` David Gibson
2026-04-13 0:53 ` [PATCH v7 02/13] passt, pasta: Introduce unified multi-address data structures Jon Maloy
2026-05-14 6:30 ` David Gibson
2026-05-14 23:28 ` Stefano Brivio
2026-05-25 9:35 ` David Gibson [this message]
2026-04-13 0:53 ` [PATCH v7 03/13] fwd: Unify guest accessibility checks with unified address array Jon Maloy
2026-05-25 9:38 ` David Gibson
2026-04-13 0:53 ` [PATCH v7 04/13] arp: Check all configured addresses in ARP filtering Jon Maloy
2026-04-13 0:53 ` [PATCH v7 05/13] conf: Allow multiple -a/--address options per address family Jon Maloy
2026-05-25 9:47 ` David Gibson
2026-04-13 0:53 ` [PATCH v7 06/13] netlink, conf: Read all addresses from template interface at startup Jon Maloy
2026-04-13 0:53 ` [PATCH v7 07/13] netlink, pasta: refactor function pasta_ns_conf() Jon Maloy
2026-04-13 0:53 ` [PATCH v7 08/13] conf, pasta: Track observed guest IPv4 addresses in unified address array Jon Maloy
2026-04-13 0:53 ` [PATCH v7 09/13] conf, pasta: Track observed guest IPv6 " Jon Maloy
2026-04-13 0:53 ` [PATCH v7 10/13] migrate: Update protocol to v3 for multi-address support Jon Maloy
2026-04-13 0:53 ` [PATCH v7 11/13] dhcp: Select address for DHCP distribution Jon Maloy
2026-04-13 0:53 ` [PATCH v7 12/13] dhcpv6: Select addresses for DHCPv6 distribution Jon Maloy
2026-04-13 0:53 ` [PATCH v7 13/13] ndp: Support advertising multiple prefixes in Router Advertisements Jon Maloy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ahQX6Q2nUO5l9dbE@zatzit \
--to=david@gibson.dropbear.id.au \
--cc=jmaloy@redhat.com \
--cc=passt-dev@passt.top \
--cc=sbrivio@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://passt.top/passt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).