From: Hannes Laimer <h.laimer@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: [PATCH proxmox-ebpf v4 0/5] add proxmox-ebpf library
Date: Mon, 19 Oct 2026 16:24:07 +0200 [thread overview]
Message-ID: <20261019142413.2255644-1-h.laimer@proxmox.com> (raw)
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 is swapped onto the existing links without interrupting traffic.
A changed map schema keeps the links as well and starts with empty maps,
which the same call refills. 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. 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.
Changes since v3, 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 | 1024 ++++++++++++++++++++++++++++++++
src/tc.rs | 313 ++++++++++
tests/common/mod.rs | 207 +++++++
tests/harness.rs | 65 ++
18 files changed, 1963 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, 1963 insertions(+), 0 deletions(-)
--
Generated by murpp 0.12.0
next reply other threads:[~2026-10-19 14:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-19 14:24 Hannes Laimer [this message]
2026-10-19 14:24 ` [PATCH proxmox-ebpf v4 1/5] tc: add the link plumbing Hannes Laimer
2026-10-19 14:24 ` [PATCH proxmox-ebpf v4 2/5] subsystem: add the shared tc program handling Hannes Laimer
2026-10-19 14:24 ` [PATCH proxmox-ebpf v4 3/5] subsystem: place the links of different subsystems in a fixed order Hannes Laimer
2026-10-19 14:24 ` [PATCH proxmox-ebpf v4 4/5] tests: add a native harness for the BPF C programs Hannes Laimer
2026-10-19 14:24 ` [PATCH proxmox-ebpf v4 5/5] debian: package the crate as a Rust library Hannes Laimer
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=20261019142413.2255644-1-h.laimer@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