From: Stefano Brivio <sbrivio@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: passt-dev@passt.top
Subject: Re: [PATCH 06/18] fwd: Better split forwarding rule specification from associated sockets
Date: Wed, 08 Apr 2026 23:39:55 +0200 (CEST) [thread overview]
Message-ID: <20260408233954.51bb5530@elisabeth> (raw)
In-Reply-To: <adWvtcigSZMESRS_@zatzit>
On Wed, 8 Apr 2026 11:30:29 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:
> On Wed, Apr 08, 2026 at 01:14:46AM +0200, Stefano Brivio wrote:
> > On Tue, 7 Apr 2026 13:16:18 +1000
> > David Gibson <david@gibson.dropbear.id.au> wrote:
> >
> > > 6dad076df037 ("fwd: Split forwarding rule specification from its
> > > implementation state") created struct fwd_rule_state with a forwarding rule
> > > plus the table of sockets used for its implementation. It turns out this
> > > is quite awkward for sharing rule parsing code between passt and the
> > > upcoming configuration client.
> >
> > Indeed, I hated it, in that short moment I had to fiddle with it. Thanks
> > for coming up with a cleaner solution.
>
> Yeah, mea culpa. Seemed like a good idea at the time, but it wasn't.
>
> [snip]
> > > /**
> > > - * struct fwd_table - Table of forwarding rules (per initiating 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
> >
> > I don't see this as particularly descriptive (which sockets? What's
> > the array size?). I'm thinking of something like:
> >
> > @socks_ref: Per-rule pointers to associated @socks, @sock_count of them
>
> There are @count of them, not @sock_count...
Oops, "of course"...
> which I guess just
> emphasises the need for a better description. How's this:
>
> * 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
"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) ...".
For the rest, yes, it's better, but I started wondering if we could
simplify the representation a bit by, either:
1. storing indices instead of int *, or
2. storing start and end. I'm not sure if it's usable, but it would
actually look easier to describe
if neither of these applies (I didn't really think it through), maybe
this is slightly more intuitive:
* Pointers to entry in @socks (@count of them) with first socket for each rule
? If not, I think the version you just proposed is better than the
original and sufficiently clear anyway.
> * @sock_count: Number of entries used in @socks (for all rules combined)
> * @socks: Listening sockets for forwarding
>
> > > * @sock_count: Number of entries used in @socks
> > > * @socks: Listening sockets for forwarding
> > > */
> > > struct fwd_table {
> > > unsigned count;
> > > - struct fwd_rule_state rules[MAX_FWD_RULES];
> > > + struct fwd_rule rules[MAX_FWD_RULES];
> > > + int *rulesocks[MAX_FWD_RULES];
> > > unsigned sock_count;
> > > int socks[MAX_LISTEN_SOCKS];
> > > };
> >
> > --
> > Stefano
> >
>
--
Stefano
next prev parent reply other threads:[~2026-04-08 21:40 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-07 3:16 [PATCH 00/18] Rework forwarding option parsing David Gibson
2026-04-07 3:16 ` [PATCH 01/18] conf: Split parsing of port specifiers from the rest of -[tuTU] parsing David Gibson
2026-04-07 3:16 ` [PATCH 02/18] conf: Simplify handling of default forwarding mode David Gibson
2026-04-07 23:14 ` Stefano Brivio
2026-04-08 1:10 ` David Gibson
2026-04-07 3:16 ` [PATCH 03/18] conf: Move first pass handling of -[TU] next to handling of -[tu] David Gibson
2026-04-07 3:16 ` [PATCH 04/18] doc: Consolidate -[tu] option descriptions for passt and pasta David Gibson
2026-04-07 23:14 ` Stefano Brivio
2026-04-08 1:23 ` David Gibson
2026-04-07 3:16 ` [PATCH 05/18] conf: Permit -[tTuU] all in pasta mode David Gibson
2026-04-07 3:16 ` [PATCH 06/18] fwd: Better split forwarding rule specification from associated sockets David Gibson
2026-04-07 23:14 ` Stefano Brivio
2026-04-08 1:30 ` David Gibson
2026-04-08 21:39 ` Stefano Brivio [this message]
2026-04-09 0:47 ` David Gibson
2026-04-07 3:16 ` [PATCH 07/18] fwd_rule: Move forwarding rule formatting David Gibson
2026-04-07 3:16 ` [PATCH 08/18] conf: Pass protocol explicitly to conf_ports_range_except() David Gibson
2026-04-07 3:16 ` [PATCH 09/18] fwd: Split rule building from rule adding David Gibson
2026-04-07 3:16 ` [PATCH 10/18] fwd_rule: Move rule conflict checking from fwd_rule_add() to caller David Gibson
2026-04-07 23:14 ` Stefano Brivio
2026-04-08 1:37 ` David Gibson
2026-04-08 4:42 ` David Gibson
2026-04-07 3:16 ` [PATCH 11/18] fwd: Improve error handling in fwd_rule_add() David Gibson
2026-04-08 21:40 ` Stefano Brivio
2026-04-09 0:10 ` David Gibson
2026-04-07 3:16 ` [PATCH 12/18] conf: Don't be strict about exclusivity of forwarding mode David Gibson
2026-04-08 21:40 ` Stefano Brivio
2026-04-09 0:12 ` David Gibson
2026-04-07 3:16 ` [PATCH 13/18] conf: Rework stepping through chunks of port specifiers David Gibson
2026-04-08 21:40 ` Stefano Brivio
2026-04-09 0:13 ` David Gibson
2026-04-07 3:16 ` [PATCH 14/18] conf: Rework checking for garbage after a range David Gibson
2026-04-08 21:40 ` Stefano Brivio
2026-04-09 0:15 ` David Gibson
2026-04-07 3:16 ` [PATCH 15/18] conf: Move "all" handling to port specifier David Gibson
2026-04-08 21:40 ` Stefano Brivio
2026-04-07 3:16 ` [PATCH 16/18] conf: Allow user-specified auto-scanned port forwarding ranges David Gibson
2026-04-08 21:40 ` Stefano Brivio
2026-04-07 3:16 ` [PATCH 17/18] conf: Move SO_BINDTODEVICE workaround to conf_ports() David Gibson
2026-04-07 3:16 ` [PATCH 18/18] conf: Don't pass raw commandline argument to conf_ports_spec() David Gibson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260408233954.51bb5530@elisabeth \
--to=sbrivio@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=passt-dev@passt.top \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://passt.top/passt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).