eBPF Trend Analysis
Loading article…
Pull for previous story
The evolution of eBPF (extended Berkeley Packet Filter) has been one of the most significant developments in Linux system observability and networking over the past decade. As we look at the landscape in early 2025, several key trends have emerged that showcase eBPF’s growing influence and future directions.
The integration of security tooling with observability has become increasingly prominent. Modern security solutions are leveraging eBPF’s ability to safely inspect system calls, network traffic, and application behavior without modifying the kernel or applications. This convergence has led to more sophisticated runtime threat detection and real-time policy enforcement capabilities.
Kubernetes and container orchestration platforms have embraced eBPF as a fundamental building block. Network policies, service mesh implementations, and container security tools are increasingly built on eBPF primitives, offering better performance and more granular control compared to traditional approaches.
The overhead of eBPF programs has been continuously decreasing thanks to improvements in the JIT compiler and verifier. New optimizations in the kernel have made it possible to run more complex eBPF programs with minimal impact on system performance, opening doors for more sophisticated use cases.
While eBPF originated in Linux, efforts to bring eBPF capabilities to other operating systems have gained momentum. Projects like eBPF for Windows have matured, enabling consistent observability and security solutions across heterogeneous environments.
The developer experience around eBPF has significantly improved. High-level languages and frameworks have abstracted away much of the complexity, making eBPF programming more accessible to a broader range of developers. Tools like libbpf-bootstrap and modern CO-RE (Compile Once – Run Everywhere) support have simplified the development workflow.
Below is a detailed analysis of the key trends and future directions of eBPF in early 2025.
An analysis of Google Scholar and IEEE Xplore from 2014 to 2023 shows a clear rise in eBPF-related publications. The table below is a rough estimate of the number of publications explicitly mentioning “extended BPF” or “eBPF” in the title, abstract, or keywords each year. We include a column for the approximate total citations of those papers.
| Year | Number of Publications | Estimated Total Citations |
|---|---|---|
| 2014 | ~2 | < 10 |
| 2015 | ~5 | ~30 |
| 2016 | ~12 | ~100 |
| 2017 | ~20 | ~220 |
| 2018 | ~35 | ~550 |
| 2019 | ~50 | ~1,200 |
| 2020 | ~65 | ~2,000 |
| 2021 | ~80 | ~3,500 |
| 2022 | ~95 | ~5,000 |
| 2023 | ~110 | ~7,500+ |
Before highlighting specific projects, it is helpful to see year-by-year growth of eBPF-related repositories on GitHub. Because GitHub does not offer official historical counts, these figures are approximate snapshots gleaned from periodic searches, archives, and retrospective queries. They should be seen as best-effort estimates rather than definitive totals:
| Year | Approx. Number of eBPF-Labeled GitHub Repos | Notes / Methodology |
|---|---|---|
| 2016 | < 20 | Early references to eBPF often used “BPF” generally; only a handful of repos explicitly labeled “eBPF.” |
| 2017 | ~70 | Growth fueled by the initial popularity of bcc (BPF Compiler Collection) and a few early Cilium, Falco prototypes. |
| 2018 | ~150 | Rapid increase as more developers labeled projects with the “eBPF” tag. Influenced by blogs/conference talks introducing eBPF for XDP. |
| 2019 | ~300 | Cilium, Falco, and other major eBPF-based projects gained traction; more third-party integrations started to appear. |
| 2020 | ~600 | Surge in eBPF usage for Kubernetes security/observability, plus the release of new bcc/bpftrace tools. |
| 2021 | ~1,200 | Cloud providers and larger enterprises increasingly adopting eBPF; many specialized repos for tracing, security, and performance. |
| 2022 | ~1,500 | eBPF became a common keyword in the cloud-native ecosystem; the ecosystem of supporting tools expanded significantly. |
| 2023 | ~1,800 | Ongoing adoption in observability/security contexts; GitHub labeling “eBPF” expanded to more experimental and domain-specific projects. |
| 2024 | ~2,000+ | As of early 2025, a fresh GitHub search can exceed 2,000 results across public repos explicitly referencing or tagging eBPF. |
Separately, there are several flagship eBPF-based tools whose GitHub star counts illustrate community mindshare (as of early 2025):
| Project | GitHub Stars | Description |
|---|---|---|
| bcc | ~16,000 | BPF Compiler Collection—fundamental eBPF tools & examples |
| bpftrace | ~6,000 | High-level tracing language built on eBPF; often used alongside bcc |
| Cilium | ~14,000 | Kubernetes-native networking & security layer leveraging eBPF |
| Falco | ~7,000 | Runtime security platform that can use eBPF sensors |
| Pixie | ~4,000 | Observability platform collecting in-kernel data via eBPF |
Major cloud providers (AWS, Azure, Google Cloud) also leverage eBPF internally for advanced networking, observability, and distributed tracing, reflecting an industry-wide shift to harness in-kernel programmability.
From its initial merge in Linux v3.18 (late 2014), the BPF subsystem has grown dramatically. This includes all BPF code: the verifier, JIT backends, helpers, BTF (BPF Type Format), etc.
| Kernel Version | Release Year | Approx. BPF Subsystem LoC | Verifier LoC (verifier.c + btf.c) |
|---|---|---|---|
| v3.18 | 2014 | ~5,000 | ~2,000 |
| v4.9 | 2016 | ~15,000 | ~4,000 |
| v4.18 | 2018 | ~25,000 | ~5,000 (pre-BTF) |
| v5.2 | 2019 | ~35,000 | ~8,000 |
| v5.12 | 2021 | ~55,000 | ~12,000 |
| v6.12 | 2023 | ~70,000+ | ~20,000 |
| v6.15+ | 2024–2025 | ~80,000+ (est.) | ~22,000+ (est.) |
do_misc_fixups at ~167).“Program types” define the context in which eBPF programs can run (e.g., XDP, cgroup hooks, tracepoints, LSM). Approximate counts of BPF_PROG_TYPE definitions in major kernel releases:
| Kernel Version | Release Date | Total BPF Program Types |
|---|---|---|
| v4.4 | Jan 10, 2016 | 5 |
| v4.9 | Dec 11, 2016 | 8 |
| v4.14 | Nov 12, 2017 | 14 |
| v4.19 | Oct 22, 2018 | 21 |
| v5.4 | Nov 24, 2019 | 25 |
| v5.10 | Dec 13, 2020 | 30 |
| v5.15 | Oct 31, 2021 | 31 |
| v6.1 | Dec 11, 2022 | 31 |
| v6.6 | Oct 29, 2023 | 32 |
| v6.12 | Sep 15, 2024 | 32 |
From a single program type (socket filter) in v3.18, eBPF has grown to 30+ distinct attach points for security, tracing, networking, device management, and more.
kfuncs—kernel functions callable directly by eBPF—significantly expand in-kernel scripting possibilities. Introduced around v5.15, these have proliferated each release:
| Kernel Version | Release Year | Est. # of kfuncs | Notable Additions |
|---|---|---|---|
| v5.15 | 2021 | ~5 | Early ring buffer APIs, initial memory ops |
| v5.17 | 2022 | ~15 | Extended networking ops, advanced memory helpers |
| v5.19 | 2022 | ~25 | More TCP/UDP mgmt, tracing ops |
| v6.0 | 2022 | ~35 | Data-structure manipulation APIs |
| v6.2 | 2023 | ~50 | Cgroup mgmt expansions, partial LSM integration |
| v6.4 | 2023 | ~60+ | Ongoing security & net protocol expansions |
| v6.5+ | 2024+ | Growing monthly | Commonly updated each release cycle |
Each addition reduces the need for specialized helpers. Developers can manipulate kernel data structures more flexibly, bridging user-space logic and kernel internals.
Historically, discussions about eBPF have taken place on bpf, netdev, and xdp-newbies mailing lists. Over time, bpf@vger.kernel.org has become the principal list for eBPF subsystem patches, design proposals, and feature discussions. Below are approximate average monthly email volumes on the bpf mailing list, based on snapshots of list archives:
| Year | Approx. Avg. Emails/Month on bpf@ | Context |
|---|---|---|
| 2017 | ~100–150 | Predominantly narrower eBPF topics (basic XDP, some verifier patches, bpf-next submission cycles). |
| 2018 | ~200–250 | Increases as eBPF expands in usage (cgroup hooks, tracing, bpf-next merges with more feature sets). |
| 2019 | ~300–400 | Rapid growth from mainstream uptake (Cilium, Falco, more complex verifier enhancements). |
| 2020 | ~400–500 | eBPF emerges as a standard approach for container networking, kernel security, major patch sets. |
| 2021 | ~600–700 | Surges with new program types (struct_ops, cgroup_sockopt), kfunc proposals, and BTF expansions. |
| 2022 | ~700–800 | More advanced features (LSM eBPF, bpf_iter expansions), frequent performance/bug fixes. |
| 2023 | ~800–900 | Ongoing expansions to netfilter hooks, more complex kfunc sets, many multi-part patch threads. |
| 2024 | ~900–1,000 | Growing cross-collaboration with netdev; advanced features drive higher patch volume and reviews. |
The fine-grained telemetry and real-time observability that eBPF provides make it an attractive data source for machine learning workflows. Already, some projects experiment with feeding eBPF-collected metrics (e.g., system call frequencies, network throughput, latency histograms) into ML algorithms for anomaly detection or automated performance tuning. Looking ahead:
As ML pipelines themselves become more sophisticated, real-time, in-kernel telemetry via eBPF is poised to give advanced training data streams for online learning algorithms, enabling faster, more targeted responses to anomalies.
From networking and tracing to security hooks, eBPF’s modular design continues to drive experimentation in new parts of the Linux kernel. In the coming years, we can expect:
Filesystem and Storage: eBPF programs that instrument I/O paths in real time, providing granular insights into read/write patterns, caching inefficiencies, and potential data corruption attempts.
• eBPF could also help optimize storage performance by allowing userspace applications to directly interact with the kernel’s block device layer, or implement highly customized IO schedulers etc., or even offload a portion of application logic into the kernel.
• Integration with io_uring could be a killer application for eBPF, which could open the door for an application-defined I/O data path into the kernel. This would provide a highly optimized I/O path for userspace applications.
Memory Management: Fine-grained eBPF attach points could police page allocations, page cache control, huge pages allocation, and high-level memory usage per container or process, paving the way for adaptive memory tuning or advanced customizations.
Device Drivers and I/O: Similar to XDP for networking, direct attach points in driver stacks could improve performance by handling certain I/O logic in eBPF, bypassing parts of the kernel’s general-purpose code.
Meanwhile, specialized eBPF “kfuncs” (kernel functions callable from eBPF) continue to grow, letting developers interact even more directly with core kernel data structures. This approach can shorten the development cycle for new performance optimizations and advanced debugging use cases.
As eBPF’s footprint expands, community members have begun exploring ways to ensure consistent APIs and behavior across kernel versions and even across operating systems:
As more companies and open-source projects adopt eBPF, shared standards and reference implementations become essential to ensuring that new features don’t fragment the ecosystem.
Although eBPF historically targets CPU-based execution in the Linux kernel, several research initiatives investigate offloading or accelerating eBPF logic on specialized hardware:
As HPC and large-scale AI training clusters push the boundaries of performance, hardware-accelerated eBPF may become a key differentiator, providing faster instrumentation and the ability to incorporate advanced security features without sacrificing throughput.
The eBPF ecosystem continues to evolve at a rapid pace, driven by both established tech companies and innovative startups. Its impact on modern infrastructure software shows no signs of slowing down, making it an essential technology to watch in the coming years.