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=bIATyz7m; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id 95C135A0262 for ; Fri, 10 Jul 2026 23:40:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1783719639; 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=KhpzKcAVhg/niWbqKRvzCEkkbcxgnsmKUYmSQBVOeiY=; b=bIATyz7mR0Q/ZcJSbAzRoync4TFes4Krrs9rA89yRiT8tY2B74295AV8HLiYww43WM2gaU MNHuDatDgHPMkkCLPXf4BXKx5WXQ/z0pQ73dEN3FEPLvCWO3IbgnY62Yzig/FmrQlGIC3E 2klEL+YiM9p4yYK6nlzfZgQ0rVxf9y0= Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-332-YtDNzJo1MkmZs1tv4lpPBw-1; Fri, 10 Jul 2026 17:40:38 -0400 X-MC-Unique: YtDNzJo1MkmZs1tv4lpPBw-1 X-Mimecast-MFC-AGG-ID: YtDNzJo1MkmZs1tv4lpPBw_1783719638 Received: by mail-qv1-f70.google.com with SMTP id 6a1803df08f44-8eeba1d9e47so16577226d6.2 for ; Fri, 10 Jul 2026 14:40:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783719638; x=1784324438; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=KhpzKcAVhg/niWbqKRvzCEkkbcxgnsmKUYmSQBVOeiY=; b=EgxYku8cF16Gbb1q8Ffm83LwuvLw5qu/Sds2TOzonJCpi9gjdCwOG5RepQBfvFAHnY 9W7hhS7P87qKQ3fil4RGO4v+eI4ZHG73UANOyvO0tWxXSLMD3XIWtJdGVTjhasPyl0HM 0aEZQlKq+YyGw+I6n30GPuZ9OIsCTTgf1EX4kwrEk/dYlzUMbF/NbSoMDANrK0WfiQdJ VNUB7Kpe5QjT8bgHxhwoZe5COJMzd/NiM8YY6U16zWbWhFNWG1Ge8g1E7HwwP2ISc7Ig JU0O8YqJgp6ezUEE96MI+b6DXFIt0lfAjAeeoS34f7KNHEM0fkxCepa5iitqGwbrquz8 L8lA== X-Forwarded-Encrypted: i=1; AHgh+RrqYsuQs5qrgbxIAMlpPd2DZ/r2d4uRRBc7ZZ7lXU/Y7NnabN4JyVuaw6Ivg2FAnqjtun0RxV4h9m0=@passt.top X-Gm-Message-State: AOJu0YzSCFW0xSdwLmlGbCcDiYOymtMGbtsmlJEgqAuS9F98gr+E5eDA KdeVBkfA3X5fML+QIDhebYHnfxv+uUjE9FVWVJbtbET0BU2iGJ3CRv71h31qzInZesRTl9381hq 8uNpURg3en+kSN9i1kiClaB2EJcLJ0/vWhp5sf1XKPaYarcgpoEMQ9g== X-Gm-Gg: AfdE7cmaDjcW73Lz68jRBGoP3BfMekbnjYf22yBUtM06Eky7YxoaSzx4cfaWZ4pZodR 0Q0T+qHFhP+mqs08hh5yqamYvLvovcYcMY8Y/+RyzoQ/++iZAoxiO2XT88W/8xgFWgf1K3HesIA 7RzidgArU/OD67NsDp+9FjOylYFM4nt+RVxAAu2t0+omKqeawljEBG5VCS/gOUvC5q4jOxSdTyS RU949BO/6cbrIKkrtVUuI7vBT3IdbnEAHnHn/hEL1bSgbt98DwcOnXfphdIAgG7I3L8YnnRsRfI kWeb/IA03X7f8eqYE84C2acDCsVWKhCAxHLzE6TbxVR70LWKx4jkHir4CCiMCAflr8y7qZYUXCC PC1sWkuEB//UdLFRReOA/PcXHxi36HMj9zunwYLh0SHw3CoHpIvhcv+JkuXox62fg24xd+Ef+e8 7tAsM= X-Received: by 2002:a05:6214:411a:b0:8f3:cf36:15ca with SMTP id 6a1803df08f44-903fe450e99mr9415976d6.9.1783719637306; Fri, 10 Jul 2026 14:40:37 -0700 (PDT) X-Received: by 2002:a05:6214:411a:b0:8f3:cf36:15ca with SMTP id 6a1803df08f44-903fe450e99mr9415646d6.9.1783719636724; Fri, 10 Jul 2026 14:40:36 -0700 (PDT) Received: from [192.168.2.15] (lnsm6-montreal02-142-122-43-198.internet.virginmobile.ca. [142.122.43.198]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8ffd86d43e2sm51197756d6.43.2026.07.10.14.40.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Jul 2026 14:40:36 -0700 (PDT) Message-ID: Date: Fri, 10 Jul 2026 17:40:35 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 02/14] passt, pasta: Introduce unified multi-address data structures To: David Gibson References: <20260626024519.3701556-1-jmaloy@redhat.com> <20260626024519.3701556-3-jmaloy@redhat.com> From: Jon Maloy In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 6ChFCER-Q7b8uEYKDZ2o1BjAuO3oCuCP4-BjBFPMrKA_1783719638 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: EQQCH5OQGAOLNGYIHPZBNYXOSSCSI2YU X-Message-ID-Hash: EQQCH5OQGAOLNGYIHPZBNYXOSSCSI2YU X-MailFrom: jmaloy@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: sbrivio@redhat.com, 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 2026-07-09 01:56, David Gibson wrote: > On Thu, Jul 09, 2026 at 02:05:11PM +1000, David Gibson wrote: >> On Thu, Jun 25, 2026 at 10:45:07PM -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 >>> 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]. >>> >>> In conf_ip6(), the explicit IN6_IS_ADDR_UNSPECIFIED() check on the >>> address at the end of the function is no longer needed: for >>> host-discovered addresses, it is now checked inside the if (!a) block >>> before calling fwd_set_addr(); for user-provided addresses (via -a), >>> validation already rejects unspecified addresses at parse time. > > Following up with a more general observation. We've now been through > a bunch of iterations with various problems in the filtering logic of > fwd_get_addr(). On reflection I think the whole idea of a single > "get" function with a couple of mask parameters is flawed. The > conditions we want to filter on are more complex than this, because we > do have both different provenances of address and types of address. > > The major use of fwd_get_addr() in these early patches is to replace > direct references to c->ip4.addr, c->ip6.addr or c->ip6.addr_ll. In > later patches, many of these go away, because you instead iterate > through and do something for *all* relevant addresses. So, I'd > suggest instead of trying to make this general-but-actually-it's-not > lookup function you instead insert 3 specific functions: one that > retreives an ip4.addr equivalent address, one an ip6.addr equivalent > and so forth. > > That removes the evidently confusing filtering logic of fwd_get_addr() > and makes for smaller and clearer changes in the many places that need > to be changed to use the new data structure. Through the rest of the > patches callers of those will mostly go away, and they can be removed > again. > I think this is a good idea. The iteration time for this series has become intolerable because of all the back-and-forts early in the series. I will go ahead and post #1 and #6 as standalones, and then this one, also as a standalone. Maybe that will speed up the progress. /jon