Home Cloud An Introduction to eBPF Architecture (Part 2)

An Introduction to eBPF Architecture (Part 2)

by Vamsi Chemitiganti

The second post on eBPF, which follows the first one – https://www.vamsitalkstech.com/cloud/an-introduction-to-ebpf-part-1/ – will explore the architecture of this Kernel capability.

An Introduction to BPF and eBPF Architecture…

With adoption in projects such as Cilium and its incubation into the CNCF community, eBPF has begun making its presence felt.

The above diagram (source:ebpf.io) shows a high-level view of eBPF architecture. The key points to note are –

  1. Linux separates memory into kernel space and user space. Kernel space is used to run kernel code (needed to run the OS, kernel extensions) and device drivers (needed for the OS to communicate with hardware devices). User space is where application software runs. Kernel code has privileged access to the server’s hardware such as CPU, Memory, and Hard disks. On the other hand, the User space code uses system calls to access the kernel, which can be limiting to certain use cases. To overcome this limitation, Linux provides kernel modules (LKM) that can be loaded into the kernel at run time. To provide sandboxing of these LKMs, Linux provided BPF (Berkeley Packet Filter), originally in BSD, as a way of running in kernel programs. Examples of these include utilities such as tcpdump.]
  2. BPF is a VM (virtual machine) like construct which is based on a register, using which programs can be safely loaded onto the kernel and executed in a secure manner. eBPF is extended BPF and is used to drive a wide range of use cases and applications as shown in the above diagram. eBPF was launched in Kernel v3.18, which uses 10 64-bit registers, thus increasing performance significantly compared with BPF. eBPF is an
  3. While eBPF was originally intended to be used for network packet filtering, the birth of microservices and K8s has enabled it to evolve into a range of interesting projects and use cases. The OS guarantees the safety and execution efficiency of eBPF programs running inside using a JIT compiler and a verification engine.
  4. A brief timeline of eBPF evolution is presented below (source: eBPF.io). The eBPF eXpress Data Path (XDP) added in 2016 enables high-speed packet processing in a BPF application. The XDP instantaneously launches BPF programs in response to packets being received on network interfaces.

  1. eBPF uses the BPF Compiler Collection (BCC), a toolkit to create efficient and simple kernel tracing programs. A range of useful examples is provided with the BCC, which requires Linux 4.1 or above. BCC provides a C wrapper around LLVM and provides Python and Lua based front ends.
  2. The workflow of an eBPF program follows these steps. a/ eBPF is programmed as described above using the BCC. b/ The LLVM (a compiler system for Linux) then generates an ELF file which has all the code, maps with shareable data between various eBPF programs & associated metadata. Using this map structure ( a key/value store), application software running in the user space, such as tools can parse data/load them into the kernel. c/ Once loaded and before execution, the kernel checks the generated eBPF bytecode to look for any out of bounds access or if it fails kernel stability etc. b/ if the checks pass, the program is JIT (Just in Time) compiled.

eBPF Capabilities in action

The key capabilities of eBPF are as follows:

  • Programmability: While eBPF is an efficient bytecode generation engine, the combination of an event driven model as well as BCC enables programmability which enables it to be extended to use cases such as monitoring, tracing, SDN etc.
  • Extensibility: A single eBPF program can be compiled for a variety of targets such as x86, ARM etc. This extensibility is provided by the platforms themselves in that they provide compilers for eBPF programs into a native image. This enables the ability to offload their functionality into the kernel;s networking path
  • Performance: A combination of programmability and extensibility provides a pathway into high performance over a range of microservices use cases.

Conclusion

Using the above architecture and dataflow model, eBPF programs can be attached to key ingress and egress points when the kernel processes networking packets. That leads us to SDN, monitoring, tracing et al. The next blog post will introduce readers to Cilium, perhaps the most well-known eBPF-based technology.

Discover more at Industry Talks Tech: your one-stop shop for upskilling in different industry segments!

You may also like

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.