public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Hannes Laimer <h.laimer@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: superseded: [PATCH proxmox-ebpf v4 0/5] add proxmox-ebpf library
Date: Mon, 2 Nov 2026 16:13:29 +0100	[thread overview]
Message-ID: <16e23a80-c469-48f3-a081-51ad77d4947a@proxmox.com> (raw)
In-Reply-To: <20261019142413.2255644-1-h.laimer@proxmox.com>

superseded-by:
https://lore.proxmox.com/pve-devel/20261102150047.1584789-1-h.laimer@proxmox.com

On 2026-10-19 16:25, 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 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(-)
> 





      parent reply	other threads:[~2026-11-02 15:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-19 14:24 [PATCH proxmox-ebpf v4 0/5] add proxmox-ebpf library Hannes Laimer
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
2026-11-02 15:13 ` 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=16e23a80-c469-48f3-a081-51ad77d4947a@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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal