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

25 Jun 2026

      On Mon, 22 Jun 2026 11:46:45 +1000
David Gibson  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  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 
---
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