From: Hannes Laimer <h.laimer@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: superseded: [PATCH proxmox-ebpf v5 0/5] add proxmox-ebpf library
Date: Wed, 4 Nov 2026 14:50:43 +0100 [thread overview]
Message-ID: <e4f0bef7-0bf8-449a-b656-6c5d43a2735d@proxmox.com> (raw)
In-Reply-To: <20261102150047.1584789-1-h.laimer@proxmox.com>
superseded-by:
https://lore.proxmox.com/pve-devel/20261104134905.1623451-1-h.laimer@proxmox.com/
On 2026-11-02 16:09, Hannes Laimer wrote:
> proxmox-ebpf holds the eBPF programs and the code that loads, attaches
> and updates them, grouped into subsystems. It is a library only, whoever
> needs a subsystem pulls in just that one through a cargo feature and
> calls it from their side. This series is the shared part, the actual
> subsystems come as their own series on top.
>
> The core is the shared subsystem code. It takes care of everything from
> loading and attaching per interface to pinning in bpffs and tearing down
> again. So nothing has to keep running, and each call picks up where the
> last one left off. The build records a hash of the compiled object and a
> schema version per subsystem, so a call can tell what changed. A changed
> program or map schema is swapped onto the existing links without
> interrupting traffic. The new maps are filled before the links move onto
> them. The BPF C code is also built natively against a small shim, so the
> parsing and packet building logic can be tested without a kernel.
> Packaging is debcargo like the other Rust crates.
>
> Every change runs under a lock per subsystem, a full apply takes it
> exclusively and a single-interface step shared, like the pmxcfs domain
> locks. The holder reads the input of its change under the lock and
> writes before it lets go. So a change and a full apply reach the kernel
> in the order they read their input, and nothing has to order them after
> the fact. A holder that never returns makes the waiters time out instead
> of hanging them. A subsystem can also hand over the whole content of its
> maps. The programs then move onto the new content one link at a time and
> never read a mix of old and new entries, and a write the kernel refuses
> leaves the old content in place. The programs of different subsystems on
> one interface run in a fixed order. An attach places its link relative
> to the links the other subsystems already hold there, so the order holds
> however the attaches are timed, and an update keeps every link in its
> place.
>
> The series applies on top of the scaffolding commit of the repo, which
> is not on the list since it carries the vendored vmlinux.h at ~167k
> lines. It is on my staff repo along with these five commits.
>
> v5:
> * add a call that replaces the maps as a whole, it uses more space and
> writes everything instead of only what changed, but leaves the old
> content in place instead of a mix, in cases where the write fails
> with ENOMEM. Subsystems choose which they need
> * install/upgrade now also use this newly added replace path, this
> simplifies the process and also closes a hole where attached programs
> would read empty maps, shortly before they were filled after a schema
> version bump
> * the run order of the subsystems is written to
> `/run/proxmox-ebpf/order` by a full apply and every attach places by
> it, so a stale process running an older version attaches correctly
> against subsystems added by a process running a newer version
> * set correct permissions on `/run/..`
> * a build whose schema is older than the pinned one no longer counts
> its state as current, so its single steps back off as well
> * add `interrupted()` on the lock guard, true when a replacement left
> its staged set or an old schema directory behind, a full pass
> replaces then
> * an attach checks after attaching that the interface still has the
> index of its pin, one recreated under the same name in between is
> reported as gone
> * a map missing from a pinned set is reported by name
>
> v4, thanks @Stefan!:
> * drop the generation counter, a change takes the apply lock before it
> reads its input instead, so the lock order is the input order
> * new, the links of different subsystems on an interface are now
> ordered
> * the tc link plumbing is its own commit ahead of the subsystem code
> * subsystem programs are now a list of direction and name pairs
> * add short note for why not proxmox-sys's locking
> * improve tc error handling
> * fix smaller spacing and code stuff
>
>
> proxmox-ebpf:
>
> Hannes Laimer (5):
> tc: add the link plumbing
> subsystem: add the shared tc program handling
> subsystem: place the links of different subsystems in a fixed order
> tests: add a native harness for the BPF C programs
> debian: package the crate as a Rust library
>
> .gitignore | 1 +
> Cargo.toml | 7 +
> Makefile | 54 ++
> build.rs | 68 ++
> debian/changelog | 5 +
> debian/control | 50 ++
> debian/copyright | 26 +
> debian/debcargo.toml | 13 +
> debian/source/format | 1 +
> src/bpf-shim/bpf/bpf_endian.h | 12 +
> src/bpf-shim/bpf/bpf_helpers.h | 34 +
> src/bpf-shim/bpf_debug.h | 10 +
> src/bpf-shim/vmlinux.h | 70 ++
> src/lib.rs | 3 +
> src/subsystem.rs | 1146 ++++++++++++++++++++++++++++++++
> src/tc.rs | 323 +++++++++
> tests/common/mod.rs | 207 ++++++
> tests/harness.rs | 64 ++
> 18 files changed, 2094 insertions(+)
> create mode 100644 Makefile
> create mode 100644 debian/changelog
> create mode 100644 debian/control
> create mode 100644 debian/copyright
> create mode 100644 debian/debcargo.toml
> create mode 100644 debian/source/format
> create mode 100644 src/bpf-shim/bpf/bpf_endian.h
> create mode 100644 src/bpf-shim/bpf/bpf_helpers.h
> create mode 100644 src/bpf-shim/bpf_debug.h
> create mode 100644 src/bpf-shim/vmlinux.h
> create mode 100644 src/subsystem.rs
> create mode 100644 src/tc.rs
> create mode 100644 tests/common/mod.rs
> create mode 100644 tests/harness.rs
>
>
> Summary over all repositories:
> 18 files changed, 2094 insertions(+), 0 deletions(-)
>
prev parent reply other threads:[~2026-11-04 13:51 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-02 15:00 [PATCH proxmox-ebpf v5 0/5] add proxmox-ebpf library Hannes Laimer
2026-11-02 15:00 ` [PATCH proxmox-ebpf v5 1/5] tc: add the link plumbing Hannes Laimer
2026-11-02 15:00 ` [PATCH proxmox-ebpf v5 2/5] subsystem: add the shared tc program handling Hannes Laimer
2026-11-02 15:00 ` [PATCH proxmox-ebpf v5 3/5] subsystem: place the links of different subsystems in a fixed order Hannes Laimer
2026-11-02 15:00 ` [PATCH proxmox-ebpf v5 4/5] tests: add a native harness for the BPF C programs Hannes Laimer
2026-11-02 15:00 ` [PATCH proxmox-ebpf v5 5/5] debian: package the crate as a Rust library Hannes Laimer
2026-11-02 20:19 ` [PATCH proxmox-ebpf v5 0/5] add proxmox-ebpf library Thomas Lamprecht
2026-11-03 8:58 ` Hannes Laimer
2026-11-03 9:23 ` Thomas Lamprecht
2026-11-03 9:48 ` Hannes Laimer
2026-11-04 10:30 ` Fabian Grünbichler
2026-11-04 11:27 ` Hannes Laimer
2026-11-04 11:34 ` Stefan Hanreich
2026-11-04 11:50 ` Thomas Lamprecht
2026-11-04 12:36 ` Stefan Hanreich
2026-11-04 13:50 ` Hannes Laimer [this message]
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=e4f0bef7-0bf8-449a-b656-6c5d43a2735d@proxmox.com \
--to=h.laimer@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox