Re: [PATCH v7 08/13] conf, pasta: Track observed guest IPv4 addresses in unified address array

[Stefano Brivio <sbrivio@redhat.com>]

On Mon, 22 Jun 2026 11:46:45 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Sat, Jun 20, 2026 at 12:10:41AM +0200, Stefano Brivio wrote:
> > On Sun, 12 Apr 2026 20:53:14 -0400
> > Jon Maloy <jmaloy@redhat.com> wrote:
> >   
> > > We remove the addr_seen field in struct ip4_ctx and replace it by
> > > setting a new CONF_ADDR_OBSERVED flag in the corresponding entry
> > > in the unified address array.
> > > 
> > > The observed IPv4 address is always added at or moved to position 0,
> > > increasing chances for a fast lookup.
> > > 
> > > Signed-off-by: Jon Maloy <jmaloy@redhat.com>
> > > 
> > > ---
> > > v4: - Removed migration protocol update, to be added in later commit
> > >     - Allow only one OBSERVED address at a time
> > >     - Some other changes based on feedback from David G
> > > v5: - Allowing multiple observed IPv4 addresses
> > > v6: - Refactored fwd_set_addr(), notably:
> > >       o Limited number of allowed observed addresses to four per protocol
> > >       o I kept the memmove() calls, since I find no more elegant way to
> > >         do this. Performance cost should be minimal, since these parts
> > >         of the code will execute only very exceptionally. Note that
> > >         removing the 'oldest' entry implicitly means removing the least
> > >         used one, since the latter will migrate to the highest position
> > >         after a few iterations of remove/add.
> > >       o Also kept the prefix_len update. Not sure about this, but I
> > >         cannot see how the current approach can cause any harm.
> > >     - Other changes suggested by David G, notably reversing some
> > >       residues after an accidental merge/re-split with the next
> > >       commit.
> > > v7: - Changed fwd_set_addr() to only accept keeping one observed-only
> > >       address per protocol, as suggested by David.  
> > 
> > Sorry, I just spotted this in David's review of v6. Actually, I
> > think that keeping track of a few multiple observed addresses
> > (especially with different scope) might be convenient and it would
> > already be useful here together with 4/13 to avoid resolving via ARP
> > any of a few addresses recently seen from the guest.  
> 
> So.. not resolving ARPs is the one thing where we could actualy use
> multiple guest observed addresses - mostly we use it for directing
> traffic to the guest, for which we need a single address.
> 
> But.. I feel like switching the ARP resolution from "everything
> except" to "only these" would be a better solution.  That also lets
> the guest move to a brand new unused address without getting bogus DAD
> failures.

See my follow-up on 2/13 for the general topic. Specifically about
duplicate address detection: that's NDP, not ARP, and it already works
without failures because of this check in ndp(), ndp.c:

		if (IN6_IS_ADDR_UNSPECIFIED(saddr))
			return 1;

which is based on the fact that duplicate address detection packets are
sent to the unspecified address (RFC 4862, 5.4.2).

The DHCP / ARP equivalent is also taken care of because we assume we
are the relevant DHCP server for any guest / container and in that case
we wouldn't resolve duplicate address probes for IPv4 either, as we
just assigned that address to the guest / container.

-- 
Stefano