XDP: Your eBPF Packet Processing Introduction!

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 - Own work, Origin SVG PNG

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


Posted

in

, , , ,

by

Comments

2 responses to “XDP: Your eBPF Packet Processing Introduction!”

  1. […] XDP: Your eBPF Packet Processing Introduction! Performance Diagnostics Part 5- Optimising Worker Threads Learning eBPF Review Performance Diagnostics Part 4 -HTTPS Performance […]

  2. […] my previous article I discussed the what eBPF and XDP are and how they can be used for observability, security, and […]

Leave a Reply

Your email address will not be published. Required fields are marked *