passt/fwd.h, branch 2026_05_07.1afd4ed

conf, fwd: Allow switching to new rules received from pesto

2026-05-07T06:06:30+00:00

We can now receive updates to the forwarding rules from the pesto client
and store them in a "pending" copy of the forwarding tables.  Implement
switching to using the new rules.

The logic is in a new fwd_listen_switch().  For now this closes all
listening sockets related to the old tables, swaps the active and pending
tables, then listens based on the new tables.  In future we look to improve
this so that we don't temporarily stop listening on ports that both the
old and new tables specify.

Signed-off-by: David Gibson 
[sbrivio: In fwd_listen_switch(), use the destination size as argument
 to memcpy(), instead of sizeof(tmp), as suggested by Laurent]
Signed-off-by: Stefano Brivio 
Reviewed-by: Laurent Vivier

inany: Prepare inany.[ch] for sharing with pesto tool

2026-05-07T06:06:30+00:00

inany contains a number of helpful functions for dealing with addresses
which might be IPv4 or IPv6.  We're going to want to use that in pesto.
For the most part inany doesn't depend on other passt/pasta internals,
however it does depend on siphash.h, which pesto doesn't need.

Move the single dependent function, inany_siphash_feed() to siphash.h,
renaming to match.  Use that include inany.[ch] into pesto as well as
passt/pasta.  While we're there reformat pesto.c's header comment to match
the convention used in most other files.

Signed-off-by: David Gibson 
Reviewed-by: Laurent Vivier 
Signed-off-by: Stefano Brivio

fwd, conf: Move rule parsing code to fwd_rule.[ch]

2026-05-07T06:06:30+00:00

The code parsing command line options into forwarding rules has now been
decoupled from most of passt/pasta's internals.  This is good, because
we'll soon want to share it with a configuration update client.

Make the next step by moving this code into fwd_rule.[ch].

Signed-off-by: David Gibson 
Reviewed-by: Laurent Vivier 
Signed-off-by: Stefano Brivio

fwd_rule: Move ephemeral port probing to fwd_rule.c

2026-05-07T06:06:30+00:00

We want to move parsing of forward rule options to fwd_rule.c so it can
eventually be shared with a configuration client.  As a preliminary step,
move the ephemeral port probing there, which that will need to use.

Signed-off-by: David Gibson 
Reviewed-by: Laurent Vivier 
Signed-off-by: Stefano Brivio

fwd, conf: Add capabilities bits to each forwarding table

2026-04-21T00:09:35+00:00

conf_ports_spec() and conf_ports() take the global context structure, but
their only use for it is seeing if various things are possible: which
protocols and address formats are allowed in formatting rules.  Localise
that information into the forwarding table, with a capabilities bitmap.

For now we set that caps map to the same thing for all tables, but keep it
per-table to allow for the possibility of different pif types in future
that might have different capabilities (e.g. if we add a forwarding table
for the tap interface, it won't be able to accept interface names to bind).

Use this information to remove the global context parameter from
conf_ports() and conf_ports_spec().

Signed-off-by: David Gibson 
Reviewed-by: Laurent Vivier 
Signed-off-by: Stefano Brivio

fwd: Improve error handling in fwd_rule_add()

2026-04-15T21:31:51+00:00

fwd_rule_add() sanity checks the given rule, however all errors are fatal:
either they're assert()s in the case of things that callers should have
already verified, or die()s if we run out of space for the new rule.

This won't suffice any more when we allow rule updates from a
configuration client.  We don't want to trust the input we get from
the client any more than we have to.

Replace the assert()s and die()s with a return value.  Also include warn()s
so that the user gets a more specific idea of the problem in the logs or
stderr.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

fwd: Split rule building from rule adding

2026-04-15T21:31:46+00:00

Currently fwd_rule_add() both builds the struct fwd_rule and inserts it
into the table.  This will be inconvenient when we want to dynamically add
rules from a configuration client.  Alter fwd_rule_add() to take a
pre-constructed struct fwd_rule, which we build in the caller.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

fwd_rule: Move forwarding rule formatting

2026-04-15T21:31:44+00:00

In order to be shared with the upcoming configuration client, we want to
split code which deals with forwarding rules as standalone objects from
those which deal with forwarding rules as they're actually used to
implement forwarding in passt/pasta.

Create fwd_rule.c to contain code from the first category, and start off
by moving code to format rules into text for human display into it.  While
we're at it, we rework that formatting code a little to make it more
flexible.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

fwd: Better split forwarding rule specification from associated sockets

2026-04-15T21:31:42+00:00

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.

Instead keep the index of listening sockets in a parallel array in
struct fwd_table.

Signed-off-by: David Gibson 
Signed-off-by: Stefano Brivio

fwd: Split forwarding rule specification from its implementation state

2026-03-28T13:45:54+00:00

Most of the fields in struct fwd_rule give the parameters of the forwarding
rule itself.  The @socks field gives the list of listening sockets we use
to implement it.  In order to share code with the configuration update tool
pesto, we want to split these.  Move the rule specification itself into
fwd_rule.h, which can be shared with pesto.

Signed-off-by: David Gibson 
[sbrivio: Fix typos in commit message]
Signed-off-by: Stefano Brivio