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

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

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

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

Most things in ip.[ch] related purely to IP addresses and headers with
no dependency on other passt/pasta internals.  A number of these will be
useful to re-use in pesto.  The exception is ipv6_l4hdr() which uses
iov_tail.

The only caller of this is in tap.c, so move the function there.  Along
with moving the constant byteswapping functions to common.h, that lets
ip.[ch] to be linked into pesto as well as passt/pasta.

Signed-off-by: David Gibson 
Reviewed-by: Laurent Vivier 
[sbrivio: Dropped duplicate definition of __bswap_constant_32() while
 at it, reported by Laurent]
Signed-off-by: Stefano Brivio

pesto: Expose list of pifs to pesto and display them

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

Extend the dynamic update protocol to expose the pif indices and names
from a running passt/pasta to the pesto tool.  pesto records that data
and prints it out.

Signed-off-by: David Gibson 
Reviewed-by: Laurent Vivier 
[sbrivio: In read_pif_conf(), force a redundant termination of the
 interface name, the existing check isn't obvious enough for static
 checkers]
[sbrivio: Drop @resv_ left-over in description of struct
 pesto_pif_info, reported by Jon Maloy]
[sbrivio: Fix minor nits reported by Laurent]
[sbrivio: Initialise struct pesto_pif_info in conf_send_rules() with
 zeroes, otherwise the pif name might be seen as not terminated, and
 we'll expose memory from the back-end]
[sbrivio: Fix conflicts in Makefile]
Signed-off-by: Stefano Brivio

pesto, log: Share log.h (but not log.c) with pesto tool

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

In pesto we're going to want several levels of error/warning messages, much
like passt itself.  Particularly as we start to share mode code between
passt and pesto, we want to use a similar interface to emit those.  However
we don't want to use the same implementation - logging to a file or syslog
doesn't make sense for the command line tool.

To accomplish this loosely share log.h, but not log.c between pesto and
passt.  In fact, an #ifdef means even most of log.h isn't actually shared,
but we do provide similar warn(), die() etc. macros.

This includes the *_perror() variants, which need strerror().  However,
we want to avoid allocations for pesto as we do for passt, and strerror()
allocates in some libc versions.  Therefore, also move our workaround for
this to be shared with pesto.

Reviewed-by: Laurent Vivier 
[dwg: Based on changes part of a larger patch by Stefano]
Signed-off-by: David Gibson 
[sbrivio: Dropped debug_perror_() as it's not used anyway, Laurent was
 asking about its name]
[sbrivio: Fix conflicts in the Makefile caused by the fact that I'm
 not merging a previous series reworking it]
[sbrivio: For some reason, this triggers some unrelated, but valid,
 cppcheck warnings in tap.c and conf.c: fix / suppress them]
Signed-off-by: Stefano Brivio 
Reviewed-by: David Gibson

pesto: Introduce stub configuration tool

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

Build a new "pesto" binary, which will become the tool to update a running
passt/pasta's configuration.  For now, we just build a stub binary which
sets up a basic environment, parses trivial command line options but does
nothing else.

Signed-off-by: David Gibson 
[sbrivio: Dropped leading _ from comment to include guard endif,
 reported by Laurent]
[sbrivio: Formatting changes in pesto.1: use 80 columns instead of
 wrapping at about 75. Add description for -d, -h, --version.]
[sbrivio: Drop note from man page about pesto being experimental,
 we're shipping it so that people can actually use it]
[sbrivio: Fix conflicts in the Makefile as I'm not applying the
 previous series reworking it]
Signed-off-by: Stefano Brivio 
Reviewed-by: Laurent Vivier

bitmap: Split bitmap helper functions into their own module

2026-03-28T13:36:02+00:00

Currently bitmap functions are in util.[ch] along with a lot of other
stuff.  In preparation for sharing them with a configuration client, move
these out into their own files.

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

serialise: Split functions user for serialisation from util.c

2026-03-28T13:35:41+00:00

The read_all_buf() and write_all_buf() functions in util.c are
primarily used for serialising data structures to a stream during
migraiton.  We're going to have further use for such serialisation
when we add dynamic configuration updates, where we'll want to share
the code with the client program.

To make that easier move the functions into a new serialise.c
file, and rename thematically.

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

treewide: Spell ASSERT() as assert()

2026-03-20T20:05:29+00:00

The standard library assert(3), at least with glibc, hits our seccomp
filter and dies with SIGSYS before it's able to print a message, making it
near useless.  Therefore, since 7a8ed9459dfe ("Make assertions actually
useful") we've instead used our own implementation, named ASSERT().

This makes our code look slightly odd though - ASSERT() has the same
overall effect as assert(), it's just a different implementation.  More
importantly this makes it awkward to share code between passt/pasta proper
and things that compile in a more typical environment.  We're going to want
that for our upcoming dynamic configuration tool.

Address this by overriding the standard library's assert() implementation
with our own, instead of giving ours its own name.

The standard assert() is supposed to be omitted if NDEBUG is defined,
which ours doesn't do.  Implement that as well, so ours doesn't
unexpectedly differ.  For the -DNDEBUG case we do this by *not* overriding
assert(), since it will be a no-op anyway.  This requires a few places to
add a #include  to let us compile (albeit with warnings) when
-DNDEBUG.

Signed-off-by: David Gibson 
[sbrivio: Fix some conflicts and missing conversions as a result of
 applying "vu_common: Move iovec management into vu_collect()" first]
Signed-off-by: Stefano Brivio

treewide: Introduce passt_exit() helper

2025-12-12T21:20:02+00:00

In d0006fa78 ("treewide: use _exit() over exit()"), we replaced use of
the normal exit(3) with direct calls to _exit(2).  That was because glibc
exit(3) made some unexpected futex() calls, which hit our seccomp profile.

We've since had some bugs due to missing the extra cleanup that exit(3)
implemented, for which we've added explicit cleanup calls.  Specifically,
we have fflush() calls in some places to avoid leaving incomplete messages
on stdout/stderr, and in other places fsync_pcap_and_log() to avoid
leaving incomplete log or pcap files.

It's easy to forget these when adding new error paths, so instead,
implement our own passt_exit() wrapper to perform vital cleanup then call
_exit(2).  This also provides an obvious place to add any additional
cleanups we discover we need in future.

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

tcp: Adaptive interval based on RTT for socket-side acknowledgement checks

2025-12-08T08:15:36+00:00

A fixed 10 ms ACK_INTERVAL timer value served us relatively well until
the previous change, because we would generally cause retransmissions
for non-local outbound transfers with relatively high (> 100 Mbps)
bandwidth and non-local but low (< 5 ms) RTT.

Now that retransmissions are less frequent, we don't have a proper
trigger to check for acknowledged bytes on the socket, and will
generally block the sender for a significant amount of time while
we could acknowledge more data, instead.

Store the RTT reported by the kernel using an approximation (exponent),
to keep flow storage size within two (typical) cachelines. Check for
socket updates when half of this time elapses: it should be a good
indication of the one-way delay we're interested in (peer to us).

Representable values are between 100 us and 3.2768 s, and any value
outside this range is clamped to these bounds. This choice appears
to be a good trade-off between additional overhead and throughput.

This mechanism partially overlaps with the "low RTT" destinations,
which we use to infer that a socket is connected to an endpoint to
the same machine (while possibly in a different namespace) if the
RTT is reported as 10 us or less.

This change doesn't, however, conflict with it: we are reading
TCP_INFO parameters for local connections anyway, so we can always
store the RTT approximation opportunistically.

Then, if the RTT is "low", we don't really need a timer to
acknowledge data as we'll always acknowledge everything to the
sender right away. However, we have limited space in the array where
we store addresses of local destination, so the low RTT property of a
connection might toggle frequently. Because of this, it's actually
helpful to always have the RTT approximation stored.

This could probably benefit from a future rework, though, introducing
a more integrated approach between these two mechanisms.

Signed-off-by: Stefano Brivio