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=X0j0gkCP; 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 3C0035A026E for ; Thu, 25 Jun 2026 00:57:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782341824; 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=foMUd4tPddx1mtsCqrR1dXW4LfZJnNUDiqCgz53uRrc=; b=X0j0gkCPfAR2NHFcBO4CB1AveeprLxbjcXrOL35CivZGn69BxsWMqqmwS4kk0zw84EYhpo 0nMTX+XEhEyh+mOvR7iC05MEgx41I1olXXXU209eAb9FZmTh1rZk/3k0BWiiICv6yTIxOS uk3HeJcems5QqQ7Ac3bZN2JgoSRGf2s= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-629-RzFsmvfhPGesuYhQqX6KBg-1; Wed, 24 Jun 2026 18:57:02 -0400 X-MC-Unique: RzFsmvfhPGesuYhQqX6KBg-1 X-Mimecast-MFC-AGG-ID: RzFsmvfhPGesuYhQqX6KBg_1782341822 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-4642a5651d4so1580108f8f.2 for ; Wed, 24 Jun 2026 15:57:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782341821; x=1782946621; 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=foMUd4tPddx1mtsCqrR1dXW4LfZJnNUDiqCgz53uRrc=; b=gv7E5VUp4m5+ADUqjOFlO3pNxvZyOw2+P2yw4LlVzJb1zrCRIRbx+bsEfYkCcEsPSZ B1MVMNm44YFvu6W7Zp2Y5JDyjAd9D1cPGFp+xD4yjnllbj8GCmFpgUuIj5JbzhPr8bmu c9wBz98cKKfBXpE7ODt/2gywBA/u8P6p3lJJ4bWMVlJQDfDx6oV5rxpyRY6OFybTucxb bIp0gAIx/LWCy29Qx2Lx83d25ODUR9rUFl5aoFkQFQdI9+/hgTrQNNBeRIYmWZlTL/pm 0Pqx6iFAUH60uDJbVRT0gOrLzGKSc15B0pYbgvazcqi+M7+xsHRfemgCdYzQfT3csWfB Jj5g== X-Forwarded-Encrypted: i=1; AHgh+Rrvo7wjKR6Sfb0dA8PWKfJFCbh3JRSIY6HCIWx6/juuTq72ThlegGhKGor9HebW1Z58fYU+HrRm2I4=@passt.top X-Gm-Message-State: AOJu0YyF++eiZFkIGOAUV79X4Ns/G6GdRIPyGrAdVpXHaAAalFYHUSyM C8/z+smmrPuPEugshVcm5ttG4SNChm38knW64lEvDYqMHLn/KeoEk8sLoY8k5+HTad96SMha/qM z6zJW8+WKXkcuKQR8nb2trlZjA0nypyx/OR6WblBTE4JX8eZoKCMduA== X-Gm-Gg: AfdE7ckynkX7H5gTH4gu8TRrXWGEIN+RbjHLNieN4csefY1mNK9jQwqoL5Lx615NoDB JT0ltoFBRSLD/h9HQl/PABSO0ppe840ct3lmqi10XCrzpQJqOuSn8Fxa1nt5jfCdh1oucUEI/hB +RAgu5ss8DocSpba6evOWW60SxyzpS+tsalE4nB/rFmInpq8pssFHG5cwN6+Rq0VXSSJ1nsZ+dh aTrl2cwVowKRGHaKEmmqZnThlHPhWU62od70ppOrGj/i6hNEu0vuxgwr0kMBtOm4BHQATJZjJbw dHqpVDonqlD3RFHeuIaKswajRz2XRd96/HnlnWPAj1XkdBz4uHkrCnhR39eXg5NDhREv8Facq7b ueohId5vW8Y1rUz/rWH9i/Q== X-Received: by 2002:a5d:6206:0:b0:467:f84c:4ca0 with SMTP id ffacd0b85a97d-46c0b3e3a41mr6418846f8f.22.1782341821519; Wed, 24 Jun 2026 15:57:01 -0700 (PDT) X-Received: by 2002:a5d:6206:0:b0:467:f84c:4ca0 with SMTP id ffacd0b85a97d-46c0b3e3a41mr6418821f8f.22.1782341821011; Wed, 24 Jun 2026 15:57:01 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-46c1e840eefsm11759204f8f.1.2026.06.24.15.57.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jun 2026 15:57:00 -0700 (PDT) From: Stefano Brivio To: David Gibson Subject: Re: [PATCH v7 08/13] conf, pasta: Track observed guest IPv4 addresses in unified address array Message-ID: <20260625005659.47d0b293@elisabeth> In-Reply-To: References: <20260413005319.3295910-1-jmaloy@redhat.com> <20260413005319.3295910-9-jmaloy@redhat.com> <20260620001040.76c9d2b1@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: Thu, 25 Jun 2026 00:56:59 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: ADE-jAgBLm3SiWA4ISjYonONP3RRH6N9se2rPGt0Pa8_1782341822 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: WUS46H3WN7BCNIPXKEDJEP77FYS6Y34O X-Message-ID-Hash: WUS46H3WN7BCNIPXKEDJEP77FYS6Y34O 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, 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