I want to let you in on why I think XDP (eXpress Data Path) and eBPF are so awesome and will change the game when it comes to security, routing, and application delivery.

Around ten years ago a new technology called DPDK (Data Plane Development Kit) was created by Intel to enabling people like you and I to create network applications (firewalls, switches, routers, load balancers etc) in user land bypassing the hosts Kernel altogether. The benefit of this is that you are not bound by the hosts general purpose network stack. This is very cool because it allows the user to write complex packet workflows in an optimised way.

Programmability of the Linux Kernel has been a goal of eBPF (extended Berkley Packet Filter) removing the need to create tightly coupled kernel modules. Trying get a change accepted by the Linux Kernel Team and then adopted by Linux distributions. Thus eBPF can be used to create code that runs in the Kernel to observe or modifying modify behaviour in real time.

XDP provides a way to network applications to operate safely within the Kernel prior to being processed by the hosts networking stack. In the case of Cilium (an open source eBPF Kubernetes network, security, and observability platform), we can create a load-balancer that bypasses the need for kube-proxy and cloud load balancers.

Jan Engelhardt Origin SVG PNG

How is XDP Different to DPDK?

DPDK and XDP have some overlap in function around used for high-performance packet processing in network applications, however their mode of operation and capabilities are quite different.

Operation

XDP is made up of both Kernel land and user land components. Using Clang we can compile our C code targeting BPF format. We then load the code into the kernel using ip set link commands. This code can then modify the packet contents and perform 4 actions.

1. XDP_ABORTED – Error condition and drop the packet.
2. XDP_DROP – Drop the packet.
3. XDP_PASS – Allow the packet to continue to the kernel.
4. XDP_TX – Transmit the packet out the interface it was received.
5. XDP_REDIRECT – Transmit the packet out another interface or to a user land application leveraging AF_XDP.

In contrast DPDK requires that the NIC (Network Interface Card) supports DPDK, and will punt the traffic straight to a user land application. This means that the receiving application know how to process the packet rather than simple drop, pass, transmit style actions.

Use Cases

XDP is tightly linked to the Operating System kernel (both Linux and Windows) and is generally used in packet load balancing, observability, routing, and security applications (DDoS scrubbing, IPS, Firewall). Additionally, you can pass data to user land for the purposes of observing the data.

DPDK is generally used for NFV (Network Function Virtualisation) purposes such as creating a networking application such as WAN optimiser. The ability to have the entire application running in user land means incredible flexibility.

Further Reading

In the next post on XDP I will create a fully functioning XDP kernel and user land application to observe traffic prior to the kernel processing the packet.

1. Check out my review of Learning eBPF which includes a chapter on XDP.
2. Check out my review of BPF Performance Tools.
3. https://www.kernel.org/doc/html/latest/networking/af_xdp.html
4. Cilium XDP Documentation

The post XDP: Your eBPF Packet Processing Introduction! first appeared on Observe Ability.

What makes Learning eBPF different to BPF Performance tools (which I wrote about recently) is that it moves beyond theObservability and performance lens towards Security and modification behaviour inside the Linux kernel. The author Liz Rice is the Chief Open Source Officer at Isovalent and recently presented at the eBPF Virtual Summit in September of 2023. She has a lot of material available online and I’ll provide some resources towards the bottom of the article.

This book introduces eBPF in a consumable way discussing its history and how it became a vehicle to inspect and create new kernel capabilities without needing to have either created a kernel module (tied to a specific build or API) or having the code agreed upon by the community and adopted by distributions. Additionally, we understand how eBPF code is checked for safety prior to running, reducing the risk of a kernel crash in production.

As a reader I enjoyed the use of C and Python to illustrate practical examples of events being triggered (such as a packet arriving on an interface) and data being read into a program in user space. 

The hardest thing to get your head around is the different components that pull eBPF together. The author makes this easy with examples of which code is run in user space, and which code is first compiled to byte code and then JIT or assembled into machine code for execution.

The eBPF for networking described newer features such as XDP (eXpress Data Path) shows how we can create routers, firewalls, and load balancers (especially in a Kubernetes context) bypassing typical kernel behaviour. Examples are discussed including how CloudFlare and Facebook have used this capability in production.

The examples and working code are provided and you can download them in the resources below. If you’re interested in the next generation of Observability and Kernel modifications, please get yourself a copy of this book.

Resources

• https://ebpf.io
• https://github.com/lizrice/learning-ebpf
• https://github.com/lizrice/ebpf-beginners
• Buy on Amazon

The post Learning eBPF Review first appeared on Observe Ability.