Quentin Monnet

By allowing to safely load programs from user space and to execute them in the kernel, eBPF (extended Berkeley Packet Filter) has brought new possibilities to the Linux kernel, in particular in terms of tracing and network processing.

But when a program fails to load, or when it does not return the expected values, what tools do we have to examine, inspect and debug eBPF objects? This talk focuses on the different tools and mechanisms available to help eBPF developers debug their programs, at the different stages of the workflow. From bpftool to test runs, let's find the best way to track bugs!

The Linux kernel networking capabilities have been undergoing major changes over the last years. At the heart of the performance gain, eBPF (extended Berkeley Packet Filter) and XDP (eXpress Data Path) have brought new possibilities in terms of tracing and network packet processing. eBPF is a trendy topic in the Linux world, and today it needs little introduction among the SDN and NFV community. But the technology is still under heavy development, bringing new features, more flexibility, and better performance to the users. This presentation is an update on the latest evolutions in the eBPF world!

Many of those changes occur directly inside the eBPF subsystem architecture. New program types are being added. Early constraints such as the maximal number of instructions for programs, or the unavailability of loops, are changing. The internals are improved with support for debug information (BTF) or 32-bit instructions. And many new mechanisms are implemented, such as global data support, the “BPF trampoline”, batched map operations, dynamic linking. Let's review all the latest trends in eBPF kernel development!

But beyond kernel code, eBPF has grown as a full ecosystem, with a variety of tools used to work with it, or to build upon it. Bpftool, a reference utility to manage eBPF programs, keeps evolving. The networking projects using eBPF keep growing in number (e.g. Katran, Suricata, Sysdig, Hubble, Libkefir) or in features (e.g. Cilium). Let's review (briefly) some of those projects that assert eBPF as one of the essential fast dataplane solutions in the Linux world.

At the core of fast network packet processing lies the ability to filter packets, or in other words, to apply a set of rules on packets, usually consisting of a pattern to match (L2 to L4 source and destination addresses and ports, protocols, etc.) and corresponding actions (redirect to a given queue, or drop the packet, etc.). Over the years, several filtering frameworks have been added to Linux. While at the lower level, ethtool can be used to configure N-tuple rules on the receive side for the hardware, the upper layers of the stack got equipped with rules for firewalling (Netfilter), traffic shaping (TC), or packet switching (Open vSwitch for example).

This presentation reviews the needs for those filtering frameworks and the particularities of each one. Then it focuses on the changes brought by eBPF and XDP in this landscape: as BPF programs allow for very flexible processing and can be attached very low in the stack—at the driver level, or even run on the NIC itself—they offer filtering capabilities with no precedent in terms of performance and versatility in the kernel. Lastly, the third part would explore potential leads in order to create bridges between the different rule formats and to make it easier for users to build their filtering eBPF programs.

To improve the historically mediocre performances of the Linux kernel regarding high-speed networking, the community has been working hard over the last years. In particular, eBPF (extended Berkeley Packet Filter) programs, when attached to XDP (eXpress Data Path) hooks at the driver level, provide a fast in-kernel programmable data plane.

Because XDP is so low-level, the only way to move packet processing further down to earn additional performances is to involve the hardware. In fact, it is possible since kernel 4.9 to offload eBPF programs directly onto a compatible NIC, thus offering acceleration while retaining the flexibility of such programs.

Building the compatible NIC, and optimising the offload process are not trivial. The objective of this talk is to present the current state of eBPF offload, the challenges that have been overcome, and the ones that lay ahead.

Software Defined Networks (SDNs) usually involve programmable switches with limited autonomy of decision, that heavily rely on the instructions of their controller to handle “exceptions” and to adapt to traffic evolution. In an attempt to bring back some of the dataplane logic from the controller to the programmable switches, the OpenState abstraction layer has been designed, to enable efficient stateful packet processing through programmable actions occurring at the switch level.

The first part of this talk in an introduction to OpenState and includes a description of the layer as well as some example use cases. Then the implementation prototypes of OpenState realized during the project will be presented. One, in particular, will get more focus: because eBPF (extended version of Berkeley Packet Filter) can be stateful and has been conceived to reach high performances for inline packet filtering and processing, we found it to be an excellent target for OpenState.

As for the background: the work around OpenState (and its extended version, Open Packet Processor) has been achieved in the context of the BEBA research project (Horizon 2020), that tackles dataplane programmability for SDNs. Started in January 2015 and closing in March 2017, this project has entered its final stage, mostly centered on functional and performance tests for the validation of the developed prototypes.