NETMAP VS DPDK DRIVER
This is called Native mode but the catch is your driver needs to explicitly support this ( list of driver support). The best option is to hook into the device driver before the kernel allocates an SKB. XDP/eBPF programs can be attached to a couple different points. For more background on eBPF checkout the excellent Cilium reference. So our eBPF program is executed very early in the packet lifecycle, before the kernel can even operate on the packet itself (so no tcpdump or qdiscs for example). It turns out skipping SKB allocation can be really powerful since its such an expensive operation performed on every packet. The hook is set in the NIC (network interface) driver just after interrupt processing, but (ideally) before any memory allocation needed by the network stack itself (namely SKB allocation). pass onto the kernel network stack as normal, drop, abort, or send to a user space program). Since we’re in the kernel the programming language for XDP is eBPF (Extended Berkeley Packet Filter) a previously defined (and loaded) eBPF program decides the packet handling (i.e.
NETMAP VS DPDK INSTALL
The idea behind XDP is to install packet processing programs into the kernel these programs will be executed for each arriving packet. Anything else can still reliably be handled by the kernel. Ideally we can filter traffic in kernel space and only pass what we’re interested in to our user space load balancing program. A cleaner and more efficient implementation would actually bypass the kernel network stack entirely, but only for the traffic we really care about. To get this to work, however, some iptables settings were needed which felt a bit hacky. The user space load balancing program sets the appropriate fields in the TCP and IP headers. In previous Convey implementations the packets are actually being sniffed at the load balancer (Layer 2), processed and then forwarded out through a raw socket (with IP_HDRINCL option set). This is sometimes called Layer-4 switching.
Internal bookeeping is needed in the load balancer to track and manage connections as they pass through, but from the client’s perspective all communication is still occurring with the load balancer. Instead, the packet is processed, manipulated and forwarded onto a backend server where the TCP handshake occurs. How would AF_XDP fit into this load balancer project? Recall in passthrough load balancing the client’s TCP session does not terminate at the load balancer. Recent kernels (since 4.8) have supported a nice balance to this problem XDP. Of course, then the problem is our user space programs need to handle everything the kernel network stack usually abstracts from us. In many cases teams have decided to bypass the kernel altogether and perform all the network functions in user space ( DPDK and Netmap for example). With the increasing popularity of eBPF and XDP I decided to jump back in and try to squeeze out more throughput. The previous implementations of passthrough load balancing were reasonably fast, but relied heavily on the Linux kernel for packet forwarding so still lots of room for improvement. Though the original intention wasn’t for this to be an ongoing series, its become a fun project to continue hacking on so here we are Part 1 and Part 2 for reference. I’d previously written a general purpose network load balancer for fun (but not profit) which I dubbed Convey. Rust and AF_XDP Another Load Balancing Adventure
0 kommentar(er)
