Today I attended a Pre-research advising session held by the University of Colarado Boulder. Here I got to see Dr. Eric Keller discuss his research and ideas, and it was an awesome session despite it being 4:45 in the morning for myself! Here I learnt about some of the work on packet acceleration in packet processing pipelines, specifically in the Linux networking stack.

need for such technology

So my first question as a novice in this area was- why do we need this? The good ol’ 5 layer stack works fine, and if not you have kernel bypas (for example using DPDK) mechanisms to get your packets to applications. I saw some answers in one of Dr. Keller’s papers about Efficient Network Monitoring Applications in the Kernel with eBPF and XDP and in his presentation today:

1. While kernel bypass mechanisms provide high input rates, at least one CPU core is always polling the network interface card and this is a waste of those CPU clock cycles
2. Building kernel bypass techniques using something like DPDK makes us lose a lot of the base functionality present in the Linux kernel stack (such as routing tables, firewalls, sockets, IP fragmentation) hence making development for integration with legacy applications a big challenge

Whereas XDP allows to leverage eBPF early in the packet processing path- allowing for programmability which is similar to the kernel bypass methods and allowing us to use the kernel’s functions.

This now makes sense. Having a technology like XDP using eBPF lets us have high packet processing capabilities work efficiently for userspace applications who require the speed and finesse that can come with bypassing the kernel for specific cases and using kernel functions when required.

little cool stuff about BPF

eBPF allows XDP to work so that specific XDP sockets listening in the user space can get packets without having to go through the network stack in the kernel. How?

To start understanding eBPF we must probably know what this acronym stands for- the “extended” Berkeley Packet Filter. The BPF provides a mechanism to filter packets (as the name suggests), and avoiding unnecessary packet copies from the kernel to the userspace. BPF allows user-defined bytecode (how this works with tcpdump) to be executed on a kernel hook point, allowing users to execute code for certain “events” without having to write a Linux kernel module.

how does XDP fit in here?

Generally the idea is to have this hook using an user defined eBPF program to decide what to do with the packet early on in the packet entry path/RX path in the kernel. So such XDP programs (which is code written in C and uses eBPF) define the “actions” to take on a packet arrival. These actions are:

1. XDP_DROP: drop the packet, can be used in case of XDP firewalling, mitigating denial of service attacks using XDP
2. XDP_ABORTED: something went wrong during processing so had to abort
3. XDP_PASS: release the packet towards the kernel network stack so it can processed “normally”
4. XDP_TX: send the received packet back out of the same network interface card it arrived at
5. XDP_REDIRECT: allow a BPF program to redirect this packet to either another NIC or a different CPU. This would allow our XDP packets to reach userspace :-)

next steps for me

I write this as a note to myself. Now I want to try building something out of this so I can explore how applications and network functions can use XDP to perform some cool stuff!

Think I would look to start here to build a Linux router using XDP.