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=kKdEYdhT; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id AEF925A026D for ; Thu, 09 Apr 2026 02:48:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202602; t=1775695681; bh=+CHjX5ymAJv3aTiTYEkhyH1vKyeSkswAQnR/msSnwUY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kKdEYdhT0mJyaT3KA7/PnjnE6NH0YTs1krv9iqutZG6nIKT3/0ZV2WNU48qzhveBe e50AQbKw+FE+48Qsn1PKeIJZjDHsc6w4GjYgREyCXvbj/4nMbsomCdyY8Hnu6Si+uO qZaU10iKa2moEBU5uMQG00UD/DY/aH8y5B/ndD3c+4iav5GOYlnTyEtHIDru5kqfY3 N2/ORAFpiMPl6sVmwQALfSw6GkvWfnMXFZQABFNHXQao4BQV92QFq833uet8cinN/w ZMHzjKqqAhGrh8ZBfD57XAx4cHzGBO4tUNa4RShuaSVBKrwImF0UiI9FRdU2Ms5nyt 4lbNjn72e4Klg== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4frh9s2fNrz4wsP; Thu, 09 Apr 2026 10:48:01 +1000 (AEST) Date: Thu, 9 Apr 2026 10:47: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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="eR5G+fG1e5W5oF+0" Content-Disposition: inline In-Reply-To: <20260408233954.51bb5530@elisabeth> Message-ID-Hash: ZVYNIGZPRE526NYFSCODSRBQPHYRMBIZ X-Message-ID-Hash: ZVYNIGZPRE526NYFSCODSRBQPHYRMBIZ 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: --eR5G+fG1e5W5oF+0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > > > 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 forward= ing rule > > > > plus the table of sockets used for its implementation. It turns ou= t this > > > > is quite awkward for sharing rule parsing code between passt and the > > > > upcoming configuration client. =20 > > >=20 > > > Indeed, I hated it, in that short moment I had to fiddle with it. Tha= nks > > > 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] > > > > /** > > > > - * struct fwd_table - Table of forwarding rules (per initiating pi= f) > > > > + * 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 t= hem =20 > >=20 > > There are @count of them, not @sock_count... >=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 start = of the > > * corresponding rule's listening sockets within the larger array >=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) ...". Good point. > 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 We could do that, but it makes lookups of a rule's sockets more awkward for minimal benefit > 2. storing start and end. I'm not sure if it's usable, but it would > actually look easier to describe We could do that, but it means maintaining redundant information that we never actually have a reason to consult > 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 eac= h rule >=20 > ? If not, I think the version you just proposed is better than the > original and sufficiently clear anyway. I have this version now: /** * 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 pointers = to * @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 combined) * @socks: Listening sockets for forwarding */ --=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 --eR5G+fG1e5W5oF+0 Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmnW9zkACgkQzQJF27ox 2GenYA/7BygUqC1j9ba1XY3stg1AW0kndLrRh+AgmK0MI6lFkysVYPNed1RRH5U8 Ti5fM+3i4asKMwAf0Cb8eqzJxeGF+vBSiI+RssNSgtpoeH2DLwKjY4BSfOgkw7ut hqjPCLMQnyHjTmqnZIDTcYWCoZkHITvPnncHHdxxAO42RauBwBcQPFud1h6+hdpn DhYSEIDoPO/HjvA3tTkwX0iJxkglT/gF/BZe8IuKksqiJ+oL7J2Cq4SQERzvodxA EpH3cxoIJ0wND0zLLLQbkaTnttYqqCBquqnxFbpL9MRUgzBeyizsk8ULoySvJfbh x6vt2z0ZbFDFfAwa/nFQjgoFfmo7Mj+YFXbUGOVIytIY9IJ6wmndoAtwCb9WHtVW w5lF8xXIenzucWFp/RG45sfRAiYZmt7YKuWdgt35VrhWTDcULSaP72wgaXkDG5eJ xiGQZD/AvSWtXI6vZgt/lvenZecNw5JS3BbtfpYGRceDJn0KMhq1KA7Bgen4HW79 1JZtRX1Ttyu1Hfm3c50abiTDTBIjkQiWSTDIbJqiYVmY5Kz+RKLzwqB4T4Ji4j9J G7wGOnAAts6XCTAg3kuuhxuMIPBXqbMhuw21M7f1G4KqyKmJSsffdLLPkbEXkzSQ vBuIWRlTauw2w10bZ9l1dwi2BNgiKfx7nOkyztssPU2MdPEaon8= =QR2H -----END PGP SIGNATURE----- --eR5G+fG1e5W5oF+0--