eBPF stands for Extended Berkeley Packet Filter. The full version of the acronym doesn’t do much justice to the actual abilities of the technology. In Brendan Gregg’s own words: “eBPF does to Linux what JavaScript does to HTML." I encourage you to check out his work on eBPF and tracing in general.
eBPF stems from the original idea of BPF, which was to capture useful network packets directly from the kernel, without copying them to user space and then funneling them out through a network tap.
BPF filters out unnecessary traffic and retrieves only those packets that are monitored, thus reducing the overhead of copying unnecessary packets into user space, and then later sieving through them.
BPF runs code in the kernel in order to decide which packets to filter in or out. eBPF greatly extends this capability to more than packet filtering, enabling you to run arbitrary eBPF code in the kernel. Your eBPF programs can be triggered by many different types of event, not just the arrival of network packets. For example, you can trigger eBPF code to run when a kernel function starts by attaching the program to a “kprobe” event. Because it runs in the kernel, eBPF code is extremely high performance.
In the early days, it was necessary to manually write an eBPF program in bytecode. This was an error prone and tedious process. Fortunately, you can use toolkits such as BCC (BPF Compiler Collection), to write eBPF programs in modern day languages like Go and Python. More on this later in this blog.