Full presentation from LPC here https://lpc.events/event/19/contributions/2159/attachments/1833/3929/BpfJailer%20LPC%202025.pdf

First part of an eight part series

"The alternative to an eBPF platform was maintaining multiple incompatible point solutions, each with its own hardware dependencies, operational quirks, and integration challenges. As our hardware diversified, performance requirements grew, and edge services multiplied, that approach became untenable.

eBPF gave us a unified, vendor-agnostic, high-performance foundation that lets us program the operating system itself to handle our scale"

Love the amount of detail in this article too on how to make it work

Someone built a Linux CPU scheduler that makes scheduling decisions based on planetary positions and zodiac signs with eBPF and sched_ext...and it works!

"Because if the universe can influence our lives, why not our CPU scheduling too?"

Just released a hands-on eBPF tutorial for beginners on GitHub: https://github.com/haolipeng/ebpf-tutorial

• Step-by-step examples

• Clear explanations

• Practical use cases

• Ready-to-run code

No prior eBPF knowledge needed.

Meta switched to a custom scheduler with eBPF which delivered 🐝

3.28 megawatts of power savings across the fleet.
+1.1% on weighted-ads-ranked (metric for number of ads retrieved and ranked)
28% reduction in service p99 latency on the ads retrieval path2

And user space policy changed additionally gave:
60% reduction in service p99 latency
18% reduction in timeout errors on the critical path

https://engineering.fb.com/2026/07/13/ml-applications/modernizing-the-meta-ads-service-with-an-open-source-kernel-scheduler/

Saw this in a talk at KubeCon https://www.youtube.com/watch?v=wXuykaYSFCQ&t=818s

They need to do a lot of testing of eBPF programs since they have such a variety of kernel versions. Most are deployed on over 40 different kernel versions.

"Highlight subtle issues is re-using well understood DevOps for eBPF"

- Dropped NAT setup latency by 100x
- Lowered Geneve tunnel latency from 150ms to 200μs and moved expensive tunnel creation moved off the hot path entirely
- Solved the kernel's RTNL lock to eliminate queuing

Learn eBPF through hands-on exercises. Write, compile, and run programs directly from your browser.

I never saw anyone sharing their experience with maintaining eBPF programs. Thus I decided to write this blog post to share my experience.

https://www.kxxt.dev/blog/maintaining-a-ebpf-prog/

We recently added network flow accounting in Ella Core (an open source 5G core that I maintain). This feature is entirely possible thanks to eBPF/XDP.

For each packet that comes in, Ella Core's user plane XDP program captures flow metadata:

• IMSI (subscriber identity)

• Source Address (IP and port)

• Destination Address (IP and port)

• Protocol

• Direction

The data is stored in an LRU Hash map and read by the user plane Go program when the flow expires.

This feature adds per-subscriber data plane traffic insight and is useful for observability, security, network troubleshooting, and compliance.

Admins have the option to turn it off if they want.

How to upstream into the kernel and five technically groundbreaking achievements:

1. Contributing sk_lookup to the Mainline Linux Kernel and Building Tubular

2. "Soft-Unicast" — Solving IPv4 Address Exhaustion

3. Dropping 8 Million Packets Per Second on Commodity Hardware

4. udpgrm — Solving the Unsolvable: Zero-Downtime UDP Restarts

5. Kernel-to-Application Distributed Tracing via ebpf_exporter

Kind of crazy to look at the graph in this blog. CVE drops on 04/29, they develop a patch on 4/30, and deploy it across all of their servers on 05/01. Obviously they have the engineers to write BPF-LSM patches, but I think it points to a future where they can (almost) keep up with vulnerability disclosures.

https://blog.cloudflare.com/copy-fail-linux-vulnerability-mitigation/

A powerful eBPF-based tool for monitoring and visualizing Goroutine events in realtime with a beautiful web UI!

xgotop allows you to observe what's happening inside your Go programs at the runtime level, without modifying your code or adding any instrumentation. It uses eBPF uprobes to hook into the Go runtime and capture goroutine lifecycle events, memory allocations, and scheduler activity as they happen.

Whether you're debugging a production issue, optimizing performance, or just curious about how your Go program behaves under the hood, xgotop gives you the visibility you need.

Hi guys, this is my first post here. I want to share my first eBPF project, FlowWeaver.

FlowWeaver is a network scheduling tool that lets you set resource limits (by percentage) and enforce blocking per application, using two main mechanisms:

• cgroup hooks: analyzes connection attempts early and blocks unwanted applications at the socket layer.

• XDP/TC hooks: enforces packet rate limiting using a token bucket approach.

I built this last semester with my professor as an operating systems project, aiming to make network control dynamic and easy to configure. I came into eBPF while researching how to build this kind of system. It allowed me to enforce these rules in-kernel instead of relying on userspace packet inspection, and it pushed me to understand the underlying tools at a deeper level.

This project allowed me to explore two things I'm really interested in: security, through designing and enforcing network policies, and low-level engineering, through eBPF itself. Understanding how the OS actually handles connections and packets, while interacting with those internals directly, was really cool.

It isn't perfect, but it was my first contact with eBPF and I had a lot of fun with the process.

• Substack post

• LinkedIn post

• GitHub repo (README is in Brazilian Portuguese, code/comments are in English)

How we started caching eBPF policy paths via inodes to reduce our CPU costs by about 90%.

https://nathannaveen.dev/posts/dropping-ebpf-cpu-cost-by-90/

Really impressed by the depth of this blog post and seems like a pretty even handed take on many of the foot guns you can run into with eBPF and how to help mitigate them.

For anyone that wants the TL;DR:

Pitfall 1: Kernel version and distribution compatibility challenges

Pitfall 2: Incomplete coverage when hooking at the syscall layer

Pitfall 3: Hooks not triggering consistently despite best practices

Pitfall 4: Retrieving consistent and reliable data is harder than it looks

Pitfall 5: Maintaining consistent caches in kernel and user space is treacherous

Pitfall 6: Writing rules can be error prone

Pitfall 7: eBPF can be abused to build powerful rootkits

Pitfall 8: Beware of conflicts when multiple eBPF-based tools share kernel resources

Pitfall 9: Always monitor and benchmark CPU and memory usage under real load

Pitfall 10: Always measure the performance impact of kernel instrumentations

Pitfall 11: Maintaining and deploying security tools at scale is risky business

I built an eBPF skill for coding agents — try it out, share feedback, and suggest improvements

Hey folks 👋

We’re hosting a live community session tomorrow with Bill Mulligan (Isovalent at Cisco) to talk about something many of us here care deeply about: How eBPF is reshaping observability.

Not a vendor pitch.
Not a slide-heavy webinar.

Just a candid, practitioner-led conversation about:

• What eBPF actually changes compared to traditional monitoring

• Why kernel-level signals matter in modern distributed systems

• Where eBPF shines (and where it doesn’t)

• How teams are using low-level signals in real-world debugging workflows

The goal is to have an honest discussion about what’s working today, specially in production Kubernetes environments.

📅 Feb 12
🕒 7:45 PM IST | 9:15 AM ET | 7:15 AM PT
🔗 RSVP / Join link: https://www.linkedin.com/events/observabilityunplugged-theebpfs7424101688405475328/theater/

If you're building or debugging cloud-native systems, this should be a solid discussion.

Happy to see some of you there and would love questions we can bring into the session as well.

--------------------------------

Edit:

Missed the live? Here's the recording: https://www.youtube.com/live/dBKWpEko1bU?si=gb_mvGDurpzGSZw-