From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202602 header.b=hocmF+jg; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 6C16C5A0272 for ; Thu, 09 Apr 2026 10:30:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202602; t=1775723447; bh=m4Z1XZjCD1Q1xaNbFTahGuyL4N2vk7AYFOzB0ieF5KM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hocmF+jgjo9xg/4KVwkpRw8kY3kgBD4tcNBs1Iu6iadBd+8/K0ELm4+x1I4Ulc6uY A9t+2MAdMweCnnNXC9XQC4CGf7jTyMgNhPGF4rjmk98zoilBRXKhl2OPb9oIbW77EU 8drU4Yd97bBEMU5frZH6XYKy8c03lszYvinZP6tbKfTPMOoeB1XkJW6zzVAZiQR1z6 lRrEM8YMobFTH73tTtX/a87b3+vdeGVwYi0/5+wGe8NJL6aqKpCQ37R8BXDv5J9vaY swuiyGDf2lcfiFuJ0zbOLqMAOwsxwhEyx88tFqoyZjVdCeUfW/8/I33tO5YfmNlZxf q3cDjx9yrOrGg== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4frtRq6gBnz4wTc; Thu, 09 Apr 2026 18:30:47 +1000 (AEST) Date: Thu, 9 Apr 2026 18:26:54 +1000 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH 06/18] fwd: Better split forwarding rule specification from associated sockets Message-ID: References: <20260407031630.2457081-1-david@gibson.dropbear.id.au> <20260407031630.2457081-7-david@gibson.dropbear.id.au> <20260408011445.275ff479@elisabeth> <20260408233954.51bb5530@elisabeth> <20260409094056.11fc12bd@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="awoJC2ukFwL6G3Zk" Content-Disposition: inline In-Reply-To: <20260409094056.11fc12bd@elisabeth> Message-ID-Hash: FQXG7GPOL4GMTCW5OXEG3YC2ZCD2UQCF X-Message-ID-Hash: FQXG7GPOL4GMTCW5OXEG3YC2ZCD2UQCF X-MailFrom: dgibson@gandalf.ozlabs.org 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: 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: --awoJC2ukFwL6G3Zk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 09, 2026 at 09:40:57AM +0200, Stefano Brivio wrote: > On Thu, 9 Apr 2026 10:47:54 +1000 > David Gibson wrote: >=20 > > On Wed, Apr 08, 2026 at 11:39:55PM +0200, Stefano Brivio wrote: > > > On Wed, 8 Apr 2026 11:30:29 +1000 > > > David Gibson wrote: > > > =20 > > > > On Wed, Apr 08, 2026 at 01:14:46AM +0200, Stefano Brivio wrote: =20 > > > > > On Tue, 7 Apr 2026 13:16:18 +1000 > > > > > David Gibson wrote: > > > > > =20 > > > > > > 6dad076df037 ("fwd: Split forwarding rule specification from its > > > > > > implementation state") created struct fwd_rule_state with a for= warding rule > > > > > > plus the table of sockets used for its implementation. It turn= s out this > > > > > > is quite awkward for sharing rule parsing code between passt an= d the > > > > > > upcoming configuration client. =20 > > > > >=20 > > > > > Indeed, I hated it, in that short moment I had to fiddle with it.= Thanks > > > > > for coming up with a cleaner solution. =20 > > > >=20 > > > > Yeah, mea culpa. Seemed like a good idea at the time, but it wasn'= t. > > > >=20 > > > > [snip] =20 > > > > > > /** > > > > > > - * struct fwd_table - Table of forwarding rules (per initiatin= g pif) > > > > > > + * struct fwd_table - Forwarding state (per initiating pif) > > > > > > * @count: Number of forwarding rules > > > > > > * @rules: Array of forwarding rules > > > > > > + * @rulesocks: Pointers to socket arrays per-rule =20 > > > > >=20 > > > > > I don't see this as particularly descriptive (which sockets? What= 's > > > > > the array size?). I'm thinking of something like: > > > > >=20 > > > > > @socks_ref: Per-rule pointers to associated @socks, @sock_count = of them =20 > > > >=20 > > > > There are @count of them, not @sock_count... =20 > > >=20 > > > Oops, "of course"... > > > =20 > > > > which I guess just > > > > emphasises the need for a better description. How's this: > > > >=20 > > > > * struct fwd_table - Forwarding state (per initiating pif) > > > > * @count: Number of forwarding rules > > > > * @rules: Array of forwarding rules > > > > * @rulesocks: Array of @count pointers within @socks giving the st= art of the > > > > * corresponding rule's listening sockets within the larger array = =20 > > >=20 > > > "Array of @count pointers" is ambiguous in English as it might refer = to > > > pointers to @count. It obviously doesn't, but it might take a couple = of > > > readings to realise that. Simple fix: "Array of pointers (@count of > > > them) ...". =20 > >=20 > > Good point. > >=20 > > > For the rest, yes, it's better, but I started wondering if we could > > > simplify the representation a bit by, either: > > >=20 > > > 1. storing indices instead of int *, or =20 > >=20 > > We could do that, but it makes lookups of a rule's sockets more > > awkward for minimal benefit >=20 > I see. >=20 > > > 2. storing start and end. I'm not sure if it's usable, but it would > > > actually look easier to describe =20 > >=20 > > We could do that, but it means maintaining redundant information that > > we never actually have a reason to consult >=20 > Right... then let's just make this clear I suppose... >=20 > > > if neither of these applies (I didn't really think it through), maybe > > > this is slightly more intuitive: > > >=20 > > > * Pointers to entry in @socks (@count of them) with first socket for= each rule > > >=20 > > > ? If not, I think the version you just proposed is better than the > > > original and sufficiently clear anyway. =20 > >=20 > > I have this version now: > >=20 > > /** > > * struct fwd_table - Forwarding state (per initiating pif) > > * @count: Number of forwarding rules > > * @rules: Array of forwarding rules > > * @rulesocks: Parallel array ro @rules (@count valid entries) of point= ers to >=20 > s/ro/of/ (?) Oops, fixed. > > * @socks entries giving the start of the corresponding rule's > > * sockets within the larger array > > * @sock_count: Number of entries used in @socks (for all rules combine= d) > > * @socks: Listening sockets for forwarding > > */ > >=20 >=20 > ...other than that it looks pretty clear to me. >=20 > --=20 > Stefano >=20 --=20 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 --awoJC2ukFwL6G3Zk Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmnXYsEACgkQzQJF27ox 2Gf7Yw//W6PkFiIA5DlGA8/5tc7f2QKhsqj8J6RzdbBKM70rRQTukR1jNoO13dRl vbuErwDmY64dpipn6efVoCk++iISJmILG7brn8pvLEYnJBdlQlWkPtOJTwdtFKsr UmBAX032Ek26h06Yz1C7G64jEcXbv/ygbo+iCjXxs6sr/mCcVhvvF8vUQFlZTbbz o3TjU8b/KidRIVDVpU0Q8yF9V5aiSdpUTeoEgEO/l+lr8iO3oknp4jyzp33C+1Jn p8Dl2i/86SCS5x6OzgfktsN8zZqbjVyjxXCJVUwADwix+VQwBIkVMGnuFCiOSdeg E1+IA7LA9lT7sdDCJx6MH6J6Frq1KzmbA5/YCwX8JF/RjrxWBi+2Tf46F+9VxR6z DO1LX0asHOmFhiPWHVyqiUaOAc8I3yKDgn6QZRysgumZAWt62iRKczxf7EKgyCFR iYSAVcyQSkQXN2diTn+WtvUDChji4JLbv886s9hEFgcZO1unV+XNRt3ZgoxwDDsa whFQvvpNaqDDbxp0bg5Koo1G86fprswXUvXKf0gNrPVsCVa887Fy7fdyYc2ybc/1 xSRPUVhMi9vwkPFj2Vx6C/SF5PGi1v/54yM/30gtJTz2s34wYNn7oJi+d9bu/s2c 0IZeRjM1E94SW+NSfhDsQA4IkRjXJM43YHn6OKT1lBc2tzSOv/A= =EmT4 -----END PGP SIGNATURE----- --awoJC2ukFwL6G3Zk--