Skip to content

Bpfman Blog

bpfman's Integration with the AF_XDP Device Plugin and CNI for Kubernetes

AF_XDP is an address/socket family that is optimized for high performance packet processing. It takes advantage of XDP (an in Kernel fastpath), which essentially runs an eBPF program as early as possible on a network driver's receive path, and redirects the packet to an AF_XDP socket.

AF_XDP

AF_XDP sockets (XSKs) are created in Userspace and have a 1:1 mapping with netdev queues. An XSKMAP is an eBPF map of AF_XDP sockets for a particular netdev. It's a simple key:value map where the key is the netdev's queue-id and the value is the AF_XDP socket that's attached to that queue. The eBPF program (at the XDP hook) will leverage the XSKMAP and the XDP_REDIRECT action to redirect packets to an AF_XDP socket. In the image below the XDP program is redirecting an incoming packet to the XSK attached to Queue 2.

NOTE: If no XSK is attached to a queue, the XDP program will simply pass the packet to the Kernel Network Stack.

+---------------------------------------------------+
|     XSK A      |     XSK B       |      XSK C     |<---+  Userspace
=========================================================|==========
|    Queue 0     |     Queue 1     |     Queue 2    |    |  Kernel space
+---------------------------------------------------+    |
|                  Netdev eth0                      |    |
+---------------------------------------------------+    |
|                            +=============+        |    |
|                            | key |  xsk  |        |    |
|  +---------+               +=============+        |    |
|  |         |               |  0  | xsk A |        |    |
|  |         |               +-------------+        |    |
|  |         |               |  1  | xsk B |        |    |
|  | BPF     |               +-------------+        |    |
|  | prog    |-- redirect -->|  2  | xsk C |-------------+
|  | (XDP    |               +-------------+        |
|  |  HOOK)  |                   xskmap             |
|  |         |                                      |
|  +---------+                                      |
|                                                   |
+---------------------------------------------------+

The AF_XDP Device Plugin and CNI project provides the Kubernetes components to provision, advertise and manage AF_XDP networking devices for Kubernetes pods. These networking devices are typically used as a Secondary networking interface for a pod. A key goal of this project is to enable pods to run without any special privileges, without it pods that wish to use AF_XDP will need to run with elevated privileges in order to manage the eBPF program on the interface. The infrastructure will have little to no control over what these pods can load. Therefore it's ideal to leverage a central/infrastructure centric eBPF program management approach. This blog will discuss the eBPF program management journey for the AF_XDP Device Plugin and CNI.

Technical Challenges for Attaching eBPF Programs in Containers

We recently added support for attaching uprobes inside containers. The purpose of this blog is to give a brief overview of the feature, to document the technical challenges encountered, and describe our solutions for those challenges. In particular, how to attach an eBPF program inside of a container, and how to find the host Process ID (PID) on the node for the container?

The solutions seem relatively straightforward now that they are done, but we found limited information elsewhere, so we thought it would be helpful to document them here.

The uprobe implementation will be used as the example in this blog, but the concepts can (and will eventually) be applied to other program types.

Community Meeting: January 11 and 18, 2024

Hit the Ground Running

Another set of bpfman Community Meetings for 2024. There is a lot going on with bpfman in Q1 of 2024. Spending a lot of time making bpfman daemonless. I bailed for a ski trip after the Jan 11 meeting, so the notes didn't get written up. So this summary will include two weeks of meetings.

Below were some of the discussion points from the last two weeks Community Meetings.

  • Manpage/CLI TAB Completion Questions (Jan 11)
  • Kubernetes Support for Attaching uprobes in Containers (Jan 11)
  • netify Preview in Github Removed (Jan 11)
  • RPM Builds and Socket Activation (Jan 18)
  • KubeCon EU Discussion (Jan 18)

Community Meeting: January 4, 2024

Welcome to 2024!

Welcome to the first bpfman Community Meeting of 2024. We are happy to start off a new year and excited for all the changes in store for bpfman in 2024!

Below were some of the discussion points from this weeks Community Meeting.

  • bpfman-csi Needs To Become Its Own Binary
  • Kubernetes Support For Attaching uprobes In Containers
  • Building The Community

A New Logo: Using Generative AI, of course

Since we renamed the project to bpfman we are in need of a new logo. Given that the tech buzz around Generative AI is infectious, we decided to explore using generative AI to create our new logo. What we found was that it was a great way to generate ideas, but a human (me) was still needed to create the final design.

bpfd becomes bpfman

Bpfd is now bpfman! We've renamed the project to better reflect the direction we're taking. We're still the same project, just with a new name.

bpfman: A Novel Way to Manage eBPF

In today's cloud ecosystem, there's a demand for low-level system access to enable high-performance observability, security, and networking functionality for applications. Historically these features have been implemented in user space, however, the ability to program such functionality into the kernel itself can provide many benefits including (but not limited to) performance. Regardless, many Linux users still opt away from in-tree or kernel module development due to the slow rate of iteration and ensuing large management burden. eBPF has emerged as a technology in the Linux Kernel looking to change all that.