eBPF

Using eBPF within your Python program using EBPFCat

H.1308 (Rolin)
Martin Teichmann
<p>eBPF is a powerful technology, but it is often hard to use, because its toolchain is non-trivial. In my talk I present <a href="https://github.com/tecki/ebpfcat">EBPFCat</a>, a pure Python library that can generate eBPF directly without any dependency on other code beyond the Linux kernel. Unlike most eBPF implementations, no compiler is involved. Instead, the user writes Python code which generates eBPF on-the-fly at runtime.</p> <p>In EBPFCat, user- and kernel space are tightly integrated, so that both eBPF and Python code can access the same data structures. This way, one can use eBPF to write the performance critical parts of a program, while retaining the versatility of Python for the bulk of the code. This opens eBPF to a large audience who are interested in the performance boost by eBPF, but are hesitant to learn an entirely new tool set for it.</p> <p>I will go through a simple example to show that using EBPFCat it is possible to fit an entire eBPF program including its user space counterpart on a single presentation slide. For this example I also show how EBPFCat generates the eBPF bytecode.</p> <p>While EBPFCat can be employed for usual eBPF use cases, I present one well beyond typical systems-level applications: motion control. EtherCAT is a standard field bus protocol based on EtherNet. Using eBPF we can reduce the latency of communication with EtherCAT devices, allowing for real-time performance. I will show a real-world combined motion system for physics research that routinely uses EBPFCat.</p> <p>Developers new to eBPF will get a jump start into everything needed for their first project, while experienced kernel developers will be surprised just how far eBPF can take you beyond system programming.</p> <p>Links: <a href="https://github.com/tecki/ebpfcat">EBPFCat on github</a> <a href="https://ebpfcat.readthedocs.io/en/latest/">EBPFCat on readthedocs</a></p>

Additional information

Live Stream https://live.fosdem.org/watch/h1308
Type devroom
Language English

More sessions

1/31/26
eBPF
H.1308 (Rolin)
<p>eBPF programs often behave differently than developers expect, not because of incorrect logic, but because of subtle behaviours of the hookpoints themselves. In this talk, we focus on a small set of high-impact, commonly misunderstood attachment types — kprobes/fentry, tracepoints and uprobes, and expose the internal kernel mechanics that cause surprising edge cases.</p> <p>Rather than attempting to cover all eBPF hooks, this session distills a practical set of real-world gotchas that ...
1/31/26
eBPF
H.1308 (Rolin)
<p>Training large models requires significant resources and failure of any GPU or Host can significantly prolong training times. At Meta, we observed that 17% of our jobs fail due to RDMA-related syscall errors which arise due to bugs in the RDMA driver code. Unlike other parts of the Kernel RDMA-related syscalls are opaque and the errors create a mismatched application/kernel view of hardware resources. As a result of this opacity and mismatch existing observability tools provided limited ...
1/31/26
eBPF
Dylan Reimerink
H.1308 (Rolin)
<p>Any eBPF project that has started in the last couple of years is most likely written to take advantage of CO-RE, compiling your eBPF programs ahead of time, and being able to run that program on a wide range of kernels and machines.</p> <p>Before CO-RE it was common to ship the whole toolchain and compile on target. This is what Cillium currently still does. Compiling on target empowered a core value of Cilium: "you do not pay for what you do not use". But it turns out that with CO-RE ...
1/31/26
eBPF
Usama Saqib
H.1308 (Rolin)
<p>This talk will go over a number of performance and reliability pitfalls of the different eBPF program types we have discovered building production ready eBPF based products at Datadog. This includes the changing performance characteristics of kprobes over different kernel versions, reliability issues with fentry due to a kernel bug, and the pains of scaling uprobes, among other things.</p>
1/31/26
eBPF
Tommy Reilly
H.1308 (Rolin)
<p><a href="http://github.com/parca-dev/oomprof">OOMProf</a> is a Go library that installs a eBPF programs that listen to Linux kernel tracepoints involved in OOM killing and records a memory profile before your Go program is dead and gone. The memory profile can be logged as a pprof file or sent to a <a href="http://parca.dev/">Parca</a> server for storage and analysis. This talk will be a deep dive into the implementation and its limitations and possible future directions.</p>
1/31/26
eBPF
Debojeet Das
H.1308 (Rolin)
<p>XDP and AF_XDP provide a high-performance mechanism for driver-layer packet processing and zero-copy delivery of packets into userspace, while maintaining access to standard kernel networking constructs — capabilities that distinguish them from full kernel-bypass frameworks such as DPDK. However, the current AF_XDP implementation offers no efficient in-kernel mechanism for forwarding packets between AF_XDP sockets in a zero-copy manner. Because AF_XDP operates without the conventional full ...
1/31/26
eBPF
H.1308 (Rolin)
<p>The eBPF eXpress Data Path (XDP) allows high-speed packet processing applications. Achieving high throughput requires careful design and profiling of XDP applications. However, existing profiling tools lack eBPF support. We introduce InXpect, a lightweight monitoring framework that profiles eBPF programs with fine granularity and minimal overhead, making it suitable for XDP-based in-production systems. We demonstrate how InXpect outperforms existing tools in profiling overhead and ...