[PATCH 00/18] More pesto preliminaries

older
[PATCH v4] log: Add rate-limiting...

David Gibson

27 Mar 2026 27 Mar '26

5:34 a.m.

The number of preliminary patches in the pesto series has grown to the point that I think it's worth trying to get a bunch merged, while we polish the rest. Changes from pesto series v3 * Extracted just the preliminary patches, not introducing pesto itself * Several small revisions based on Stefano's feedback * Added several extra bits of preliminary rework. David Gibson (18): conf: runas can be const fwd: Comparing rule can be const vhost_user: Fix assorted minor cppcheck warnings serialise: Split functions user for serialisation from util.c serialise: Add helpers for serialising unsigned integers fwd: Move selecting correct scan bitmap into fwd_sync_one() fwd: Look up rule index in fwd_sync_one() fwd: Store forwarding tables indexed by (origin) pif fwd: Allow FWD_DUAL_STACK_ANY flag to be passed directly to fwd_rule_add() fwd, conf: Expose ephemeral ports as bitmap rather than function conf: Don't bother complaining about overlapping excluded ranges conf: Move check for mapping port 0 to caller conf: Move check for disabled interfaces earlier conf: Remove redundant warning when SO_BINDTODEVICE is unavailable pif: Limit pif names to IFNAMSIZ (16) bytes ip: Define a bound for the string returned by ipproto_name() bitmap: Split bitmap helper functions into their own module fwd: Split forwading rule specification from its implementation state Makefile | 24 +++---- bitmap.c | 99 ++++++++++++++++++++++++++++ bitmap.h | 24 +++++++ conf.c | 113 ++++++++++++++++---------------- flow.c | 35 +++++----- fwd.c | 177 ++++++++++++++++++++++++++------------------------- fwd.h | 38 +++-------- fwd_rule.h | 44 +++++++++++++ ip.c | 18 ++++-- ip.h | 2 + migrate.c | 1 + passt.h | 6 +- pcap.c | 1 + pif.c | 2 +- pif.h | 4 +- serialise.c | 123 +++++++++++++++++++++++++++++++++++ serialise.h | 21 ++++++ tcp.c | 1 + util.c | 154 +------------------------------------------- util.h | 12 ---- vhost_user.c | 16 +++-- virtio.h | 2 +- vu_common.c | 2 +- 23 files changed, 535 insertions(+), 384 deletions(-) create mode 100644 bitmap.c create mode 100644 bitmap.h create mode 100644 fwd_rule.h create mode 100644 serialise.c create mode 100644 serialise.h -- 2.53.0

Show replies by date

David Gibson

...

All current pif names are quite short, and we expect them to remain short when/if we allow arbitrary pifs. However, because of the structure of the current code we don't enforce any limit on the length.

This will become more important with dynamic configuration updates, so start enforcing a length limit. Specifically we allow pif names to be up to IFNAMSIZ bytes, including the terminating \0. This is semi-arbitrary - there's no particular reason we have to use the same length limit as kernel netif names. However, when we do allow arbitrary pifs, we expect that we might support a similar number to the number of kernel interfaces. It might make sense to use names matching kernel interface names in that future. So, re-use IFNAMSIZ to avoid surprise.

And what if... we used 128 instead, which is reasonably longer than UNIX_PATH_MAX (108, which despite the application usage in POSIX 2024.1: https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/sys_un.h.html is still commonly used a path length limit, also by passt itself)? At that point we could embed UNIX domain socket paths as PIF name (possibly with some additional specifier) which _might_ be useful to forward UNIX sockets in the https://bugs.passt.top/show_bug.cgi?id=200 sense. It's not the only way to implement it, but perhaps it's one possibility that might make sense for what we know now? What do you think? It also has the advantage of being sufficiently longer than IFNAMSIZ, so that should we ever need to have stuff like "container_A:eth0" in a PIF name, we could have it as well. -- Stefano

Stefano Brivio

2:02 p.m.

On Fri, 27 Mar 2026 15:34:12 +1100 David Gibson wrote:

...

The number of preliminary patches in the pesto series has grown to the point that I think it's worth trying to get a bunch merged, while we polish the rest.

Changes from pesto series v3 * Extracted just the preliminary patches, not introducing pesto itself * Several small revisions based on Stefano's feedback * Added several extra bits of preliminary rework.

Applied, except for 15/18 (see pending question), with two small typos in 18/18's message fixed (forwarding, configuration). -- Stefano

David Gibson

30 Mar 30 Mar

3:08 a.m.

New subject: [PATCH 15/18] pif: Limit pif names to IFNAMSIZ (16) bytes

On Sun, Mar 29, 2026 at 02:02:27PM +0200, Stefano Brivio wrote:

...

On Fri, 27 Mar 2026 15:34:27 +1100 David Gibson wrote:

...
All current pif names are quite short, and we expect them to remain short when/if we allow arbitrary pifs. However, because of the structure of the current code we don't enforce any limit on the length.

This will become more important with dynamic configuration updates, so start enforcing a length limit. Specifically we allow pif names to be up to IFNAMSIZ bytes, including the terminating \0. This is semi-arbitrary - there's no particular reason we have to use the same length limit as kernel netif names. However, when we do allow arbitrary pifs, we expect that we might support a similar number to the number of kernel interfaces. It might make sense to use names matching kernel interface names in that future. So, re-use IFNAMSIZ to avoid surprise.

And what if... we used 128 instead, which is reasonably longer than UNIX_PATH_MAX (108, which despite the application usage in POSIX 2024.1: https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/sys_un.h.html is still commonly used a path length limit, also by passt itself)?

Well, certainly we could make pif names longer...

...

At that point we could embed UNIX domain socket paths as PIF name (possibly with some additional specifier) which _might_ be useful to forward UNIX sockets in the https://bugs.passt.top/show_bug.cgi?id=200 sense.

...but I don't think that rationale is compelling. The unix socket path would be the equivalent of IP+port, not the pif. I don't see how embedding a unix path in the pif would be useful.

...

It's not the only way to implement it, but perhaps it's one possibility that might make sense for what we know now? What do you think?

It also has the advantage of being sufficiently longer than IFNAMSIZ, so that should we ever need to have stuff like "container_A:eth0" in a PIF name, we could have it as well.

That's a more convincing case. Ok, I'll expand the pif name size for the next spin. -- 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

Stefano Brivio

10:45 a.m.

New subject: [PATCH 15/18] pif: Limit pif names to IFNAMSIZ (16) bytes

On Mon, 30 Mar 2026 12:08:58 +1100 David Gibson wrote:

...

On Sun, Mar 29, 2026 at 02:02:27PM +0200, Stefano Brivio wrote:

...
On Fri, 27 Mar 2026 15:34:27 +1100 David Gibson wrote:

...
All current pif names are quite short, and we expect them to remain short when/if we allow arbitrary pifs. However, because of the structure of the current code we don't enforce any limit on the length.

This will become more important with dynamic configuration updates, so start enforcing a length limit. Specifically we allow pif names to be up to IFNAMSIZ bytes, including the terminating \0. This is semi-arbitrary - there's no particular reason we have to use the same length limit as kernel netif names. However, when we do allow arbitrary pifs, we expect that we might support a similar number to the number of kernel interfaces. It might make sense to use names matching kernel interface names in that future. So, re-use IFNAMSIZ to avoid surprise.

And what if... we used 128 instead, which is reasonably longer than UNIX_PATH_MAX (108, which despite the application usage in POSIX 2024.1: https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/sys_un.h.html is still commonly used a path length limit, also by passt itself)?

Well, certainly we could make pif names longer...

...
At that point we could embed UNIX domain socket paths as PIF name (possibly with some additional specifier) which _might_ be useful to forward UNIX sockets in the https://bugs.passt.top/show_bug.cgi?id=200 sense.

...but I don't think that rationale is compelling. The unix socket path would be the equivalent of IP+port, not the pif.

Right, that was the "obvious" idea we assumed so far, but I was thinking that if you want to stick to only PIFs and addresses in rules and flow tables (from what I understood, you would see some value in keeping that), we could think of modelling that UNIX domain socket as a PIF that can only map to a given TCP or UDP port (depending on the UNIX domain socket type) instead. It's a bit of a stretch but maybe it's convenient? On the other hand it would conflict with the current (and perhaps only reasonable) concept of PIF, that is, "the host", "the guest", etc.

...

I don't see how embedding a unix path in the pif would be useful.

...and maybe something else entirely: should we, one day, add support for multiple virtual machines, with each one connecting to different UNIX domain sockets (either data or vhost-user control sockets), would it be convenient to differentiate between those "TAP" (current name) PIFs using their UNIX domain socket path instead? Or would there be a separate table mapping PIF names to socket paths? This looks more elegant and flexible but I'm not sure if it's preferable to the former.

...

...
It's not the only way to implement it, but perhaps it's one possibility that might make sense for what we know now? What do you think?

It also has the advantage of being sufficiently longer than IFNAMSIZ, so that should we ever need to have stuff like "container_A:eth0" in a PIF name, we could have it as well.

That's a more convincing case. Ok, I'll expand the pif name size for the next spin.

By the way, I forgot to mention, Podman container IDs (the ID you get from 'podman create', and if I recall correctly also from Docker) are 64 hex digits, which might be convenient to represent as 64 (printable) characters (instead of 32 bytes) for users to refer to. The OCI specification (surprise) just says that it's a "string", without defining the maximum length: https://github.com/opencontainers/runtime-spec/blob/main/runtime.md#state ...anyway, if Podman, Docker, or their users want to refer to containers using those IDs, that plus IFNAMSIZ would be 80 bytes. -- Stefano

Age (days ago)

Last active (days ago)

List overview

Download

21 comments

2 participants

participants (2)

David Gibson
Stefano Brivio

[PATCH 00/18] More pesto preliminaries

tags

participants (2)