Operating eBPF
Run eBPF for real: CO-RE portability, L3AF-style zero-downtime upgrades, AI/GPU offloading, power management, and where to go next.
CO-RE: compile once, run everywhere
The portability machinery the whole book has leaned on, finally examined head-on. Kernel struct layouts differ across versions, so a hardcoded field offset breaks on the next kernel. CO-RE compiles your program once against generic types, records relocations that name the fields you touch, and patches them at load time against the target kernel's BTF. Understand the relocations, how Aya does it transparently, how aya-tool generates portable bindings, and what 'works across the fleet' actually requires.
Operating eBPF: lifecycle, pinning, and zero-downtime upgrades
A program you load in a demo dies the instant the loader exits — fine for a chapter, fatal for a service. Operating eBPF means treating programs like deployable, upgradable services: they outlive the process that loaded them, survive a loader restart, swap to a new version without dropping a packet, and keep their state across the upgrade. The three pillars are pinning, link update, and pinned maps — and the orchestrators (L3AF, bpfman) that productize them.
Offload: running eBPF off the host CPU
Every program so far has run on the host CPU in the kernel. Offload moves the work elsewhere — onto a SmartNIC's flow processor, a DPU's ARM Linux, an FPGA, or paired with GPU inference. Learn XDP's three modes and true hardware offload, why the practical 2026 answer is running ordinary eBPF on a DPU, where the FPGA and AI frontiers actually stand, and how Aya fits each.
Power and efficiency: attributing energy with eBPF
The OS bills a process for CPU time, never for joules — so per-workload energy is invisible to ordinary tools. RAPL exposes socket-level energy, and eBPF supplies the missing piece: low-overhead per-workload CPU-time shares to divide that energy by. Learn the powercap interface, the attribution model and its candid limits, where Kepler and the field stand in 2026, and the cpufreq_ext frontier where eBPF starts to control power, not just measure it.
Correlating the signals: Tempo, Mimir, and one trace
We have used the metrics half of the observability stack for sixty chapters and never touched the rest. The otel-lgtm backend also runs Tempo for traces and Loki for logs, and the real power is correlation: from a metric spike to the exact trace, from that span to its logs, from a request to the eBPF view of what the kernel did. Learn spans and trace context, what each backend is (and where Mimir fits), and how Grafana links them by trace_id — the groundwork for the capstone.
Capstone: one request, every layer
Everything the book has built, in a single request. A curl carrying a traceparent hits a FastAPI service that calls a Quarkus service; both emit spans, metrics, and logs on one trace_id, while an Aya program watches the same request at the socket layer and ties its eBPF view into that trace. The result is one investigation that reads from the HTTP span all the way down to the kernel — the payoff of sixty-two chapters.