A key benefit of that setup was that client requests were distributed across backends based on their capacity, as well as the number of connections they were handling at that point in time.

However, least-connection selection is just one of many load-balancing strategies, and it’s natural to also demonstrate how to implement other algorithms, such as (weighted) round-robin.

While round-robin is conceptually straightforward—it simply cycles through available backends—it provides a solid foundation upon which more complex algorithms can be implemented with eBPF/XDP.

🔗 Here’s the link to the coding lab.

Hope you like it 🐝

But continuous batching has a dark side: when requests compete for GPU resources inside the same batch, one expensive request can silently starve all others.

No error. No health check failure. No metric spike.

Just users waiting 10x-250x longer than expected for their first token.

We investigated a real vLLM issue reported in the last week (#37308) to understand what happens at the kernel level during these silent latency spikes.

🚀 Special thanks to David Mail, Chief Technology Officer at eScribers, for putting together this deep and practical guest post!

Setup

The investigation used the same server configuration:

python -m vllm.entrypoints.openai.api_server \
       --model Qwen/Qwen2.5-0.5B-Instruct \
       --port 8000 \
       --gpu-memory-utilization 0.95 \
       --max-model-len 32768 \
       --enable-prefix-caching

🛠️ Hardware: RTX 4090 (24GB), 4 vCPUs, Ubuntu 22.04, vLLM 0.17.1.

We ran Ingero alongside each test to trace CUDA Runtime/Driver API calls and host kernel events (scheduler context switches, memory allocations) simultaneously.

Prefix Caching Head-of-Line Blocking

What happens

6 concurrent requests arrive within 40ms:

• 4 are heavy (2048-token prompts, 128-512 output tokens) and

• 2 are light (128-token prompts, 32-64 output tokens)

All share a 32-token prefix so the prefix cache groups them together.

The light requests should complete in under 100ms!

Instead what happened:

Run 1 is just catastrophic — the light requests are 14x over threshold!

Subsequent runs settle to 2-4x because the prefix cache warms up. But that first cold-cache batch is brutal.

3 causal chains detected. The most revealing one:

[MEDIUM] cudaLaunchKernel p99=444us (6.4x p50) - 371 sched_switch events
  Timeline:
    [HOST ] 371 context switches (5.9s off-CPU)
    [CUDA ] p99=444us (6.4x p50=70us)

The per-process breakdown tells the full story…

VLLM::EngineCore (the GPU scheduling loop):

24,347 context switches, max stall 2.5 seconds
40,632 cuLaunchKernel calls, avg 29us but max 34ms
34,087 cudaLaunchKernel calls, avg 96us but max 356ms

The engine core process - the single-threaded loop that decides which requests get GPU time - was de-scheduled for 2.5 seconds in the worst case.

During that stall, the GPU kernel queue drained and the light requests had nothing submitted on their behalf.

The 356ms cudaLaunchKernel spike (3,700x the average) is the smoking gun.

And that’s not the GPU being slow. That’s the CPU failing to submit work to the GPU because the scheduling loop was preempted.

Why nvidia-smi misses this

nvidia-smi shows high utilization because the GPU is working - on the heavy requests’ pre-fills.

The light requests are starving, but from the GPU’s perspective there’s always a kernel to run.

The starvation is in the CPU-side scheduling loop, not on the GPU.

What Standard Tools Show vs What Kernel Tracing Shows

The key insight: GPU utilization was high because the GPU was doing work.

It was just doing the wrong work - processing heavy pre-fills or computation while light requests starved.

No GPU-side metric can distinguish “GPU is busy computing my request” from “GPU is busy computing someone else’s request while mine waits.”

Implications for Production vLLM

If you’re running vLLM in production with mixed workloads (different prompt sizes, some requests with logprobs or n_completions), you’re likely experiencing these silent regressions:

1. Monitor TTFT per-request, not just aggregate throughput. Aggregate metrics hide the tail - your p99 might be 100x worse than p50 during batch contention.

2. Be careful with n_completions + logprobs. A single request with n=8 and logprobs=20 can block your entire server for 11+ seconds on a cold cache. Consider routing these to dedicated instances.

3. First-request-after-idle is the worst case. This issue showed the most extreme regression on Run 1 (cold prefix cache). If your traffic is bursty, the first batch after a quiet period will hit hardest.

4. GPU utilization is not a proxy for request health. Your dashboards might show 95% utilization while individual users experience 256x TTFT regression.

Investigate It Yourself

The trace database from this investigation is in the Ingero repository:

git clone https://github.com/ingero-io/ingero.git
cd ingero && make build

# View the causal chains
./bin/ingero explain --db investigations/vllm-37308-hol-blocking.db --since 5m

# Per-process breakdown
./bin/ingero explain --db investigations/vllm-37308-hol-blocking.db --per-process --since 5m

# Connect your AI assistant for interactive investigation
./bin/ingero mcp --db investigations/vllm-37308-hol-blocking.db

Or even better - you can point any MCP-compatible AI client at the trace database and ask questions directly. No code required. First, create the MCP config file:

# /tmp/ingero-mcp-vllm.json
{
  "mcpServers": {
    "ingero": {
      "command": "./bin/ingero",
      "args": ["mcp", "--db", "investigations/vllm-37308-hol-blocking.db"]
    }
  }
}

# With Ollama (local & free: no data sent outside):
ollmcp -m qwen3.5:27b -j /tmp/ingero-mcp-vllm.json

# With Claude Code (data sent to Anthropic):
claude --mcp-config /tmp/ingero-mcp-vllm.json

Then type /investigate and let the model explore.

Follow up with questions like:

• What was the root cause?

• Which kernel calls had the highest latency spikes?

The head-of-line blocking DB (9.6MB) is available as a release asset.

I hope you find this resource helpful. Keep an eye out for more updates and developments in eBPF in next week’s newsletter.

Until then, keep 🐝-ing!

Warm regards, Teodor

And that’s exactly what Sambhav Singh, an Executive Member of ACM, did.

He came up with an idea to “upgrade” the eBPF/XDP NAT-based Load Balancer implementation by adding a new feature — load balancing based on the least number of active connections to the backends.

As is often the case, the theory is simple, but the real learning happens during implementation.

Together, we prepared this week’s lab — which, on top of the basic implementation, also guides you through building an eBPF/XDP NAT-based Weighted Least Connection Load Balancer.

🔗 Here’s the link to the coding lab.

Hope you like it 🐝

Just two weeks ago, my colleagues and I gave a talk at KubeCon—more specifically, we ran an eBPF workshop.

If I had to estimate, a little over 200 people joined. That definitely came with its challenges, but overall we were really happy with how it turned out.

Honestly, doing something like this for the first time at that scale taught me a lot—small things you only learn by actually getting up there and doing it.

Anyway, I’m back home with new challenges ahead and I’ve already put together a few interesting eBPF lab drafts for the coming weeks.

Here’s this week’s lab.

A little over a month ago, I published two labs on building a minimal service mesh using eBPF:

• Transparent Egress Proxy with eBPF and Envoy

• Transparent Ingress Proxy with eBPF and Envoy

Together, they give a solid overview of how a service mesh operates on both ends of a connection. But there’s always the question that keeps coming up—performance. Adding a middleman like Envoy into the network path inevitably introduces overhead.

So the real question is: how much of that performance cost can we actually eliminate?

In this lab, we focus on optimizing transparent redirection on the receiving side using eBPF socket acceleration.

🔗 Here’s the link to the coding lab.

Hope you like it 🐝

At first, intercepting traffic twice might seem unnecessary. In reality, it’s what enables consistent security, policy enforcement, and observability on both ends of the connection — without requiring changes to application code.

In this lab, we focus on transparent redirection on the receiving Pod. You’ll see how eBPF makes the server behave as if nothing sits in the network path, even though Envoy is handling the traffic.

🔗 Here’s the link to the coding lab.

Hope you like it🐝

But how is this possible?

I wrestled with this question for a while, so I went down that rabbit hole and built a skill-path that breaks it down so you can understand it too.

This is the first part of the series — more are coming soon.

🔗 Here’s the link to the coding lab.

Hope you like it🐝

One of the concepts that I feel is rarely talked about—but is super useful to know—is loops.

Yes, loops—like for and while in Python 😅

It might sound trivial, but there are actually 5+ ways to iterate and loop in eBPF, each with its own pros and cons.

In this week’s lab, you will learn all about them—and, most importantly, give them a try in code.

🔗 Here’s the link to the coding lab.

Hope you like it🐝

This week, we’re turning another page and zooming in on a feature that pretty much every production-grade eBPF application relies on.

Not the flashy hooks or clever programs—but the unglamorous, absolutely critical part: delivering kernel events into user space.

We’ll go beyond the basics and look at how real production systems actually do this, why they made those choices, and what breaks if you get it wrong.

And there’s a small cherry on top at the end—something I only learned about a year ago, but it completely changed how I think about designing eBPF application stacks at scale.

🔗 Here’s the link to the coding lab.

Hope you like it🐝

That was great—but I wanted to take it a step further.

In the L2 DSR load balancing approach, we were only rewriting MAC addresses, which limited the load balancer to operate within the same L2 network.

Now, we want to make these packets routable across different networks (load balancer → network-hops → backend).

With IPIP DSR Load Balancer, we solve this problem by wrapping the original IP packet inside another IP header where the outer IP header contains routable destination IPs, allowing the packet to traverse different networks.

🔗 Here’s the link to the coding lab.

Hope you like it🐝

That was great—but I wanted to take it a step further.

One downside of NAT-based load balancing is that the load balancer sits on the traffic path in both directions. This increases resource usage and can easily turn the load balancer into a bottleneck.

Think about it: the backend could just reply directly to the client, without sending the response back through the load balancer.

Another drawback is loss of client visibility. From the backend’s perspective, every request looks like it came from the load balancer itself.

To address these issues, I built a second implementation using Direct Server Return (DSR).

With DSR, backend nodes completely bypass the load balancer on the response path and send replies directly to clients—reducing load on the balancer and preserving the original client IP.

🔗 Here’s the link to the coding lab.

Hope you like it 🤞

While many of you have probably set new things to try in 2026, I decided to double down on hands-on coding labs.

The response so far has been amazing. I’ve also realized that interactive tutorials—with a terminal right next to the code—offer huge advantages over traditional text- and image-based guides you’re supposed to run locally.

Let’s be honest: we rarely do that. Out of the box, things often don’t work, dependencies are missing, and you end up installing and tweaking more than actually learning.

This week, we continue with XDP. Specifically, I’ll show you how to build an eBPF/XDP NAT-based Layer 4 load balancer in roughly 200 lines of code (plus some boilerplate).

In the next tutorial, we’ll build on this foundation and add DSR (Direct Server Return) Layer 2 load balancing and IPIP encapsulation.

🔗 Here’s the link to the coding lab.

Hope you like it 🤞

If you missed the last two XDP coding labs, here they are:

• Hands-On with XDP: eBPF for High-Performance Networking

• Network Traffic Rate Limiting with eBPF/XDP

This week, we’re building an XDP-based firewall.

But instead of a generic “drop packets at XDP” walkthrough, we’ll zoom in on one feature that most tutorials barely mention — CIDR / IP range matching with BPF_MAP_TYPE_LPM_TRIE (longest-prefix match).

It’s the difference between “block this one IP” and “block the whole subnet cleanly and efficiently” — exactly what you want when IP addresses frequently change inside known ranges.

🔗 Here’s the link to the coding lab.

When a certain binary runs and tries to access a resource, we check it against an eBPF policy map, enforce the rules, and call it a day—right?

Not really.

Consider the following example:

• sender.sh is launched to move some files from machine A to machine B.

• To do that, sender.sh starts readandsend.sh as a child process and passes it the files

In this case, when readandsend.sh is called by sender.sh, it should be allowed to read the provided files and connect to machine B’s IP.

But according to the current (static) policy stored in the eBPF map… it can’t.

So why not simply assign those file and network permissions to readandsend.sh as well?

The problem is that when permissions are assigned across different entities in a system, each entity should ideally have the minimal set of permissions required to function.

The primary reason for this is security: if a given entity is compromised, the attacker gains only a limited set of “powers.”

In the example above, we don’t want to grant readandsend.sh access to all files. Instead, we want it to inherit permissions from its parent only for the duration of the operation.

This may not be a common pattern, but supporting it would allow us to create policies that block certain operations by default and only unlock them when an authorized parent process invokes a child. In other words, capabilities remain restricted unless the correct process chain activates them.

So how hard to implement can that be?

And obviously, we can’t just invent a completely new structure. Instead, to make this possible, the eBPF map that holds the policy should:

• Support taking the union of two map entries (for inheriting permissions)

• Perform that union quickly (ideally O(1), or close to it)

• Fit within the eBPF verifier’s limitations

So… this should be easy, right?

The “Easy” Solution

To achieve this, we represent our policy entries as a bitmask, where each bit corresponds to a resource the executable is allowed to access.

Instead of storing the resource identifiers directly, we store them like this:

Instead of a single eBPF map, we use two eBPF maps:

• A map that assigns each resource an index (bit position)

• A map that stores policies as bitmasks

But why?

When checking access for sender.sh, we:

• Fetch the resource’s index

• Retrieve the binary’s policy bitmask

• Allow access if the bit at that index is set

But when sender.sh calls readandsend.sh, we can simply OR their policy bitmasks to create a combined policy and apply the same checks.

In other words, we dynamically adjust permissions based on who called the binary—while still keeping least privilege.

Here’s a small pseudocode snippet to wrap it up:

I hope you find this resource interesting. Keep an eye out for more updates and developments in eBPF in next week’s newsletter.

Until then, keep 🐝-ing!

Warm regards, Teodor and Neil

Here’s what we covered:

• What does a CNCF Ambassador actually do?

  It turns out the role is less about status and more about survival for open-source projects. The goal is simple: help the community navigate a landscape flooded with new tools and ensure worthy projects actually get adopted.

• When “CPU Usage” tells you nothing

  From European League live streams to GPS trackers on police cars in the desert, simulating massive loads used to be the only way to understand system limits. But simply knowing a CPU is “waiting” isn’t enough. Is it waiting on disk? On the network? We discussed why traditional observability fail in modern architectures and how eBPF provides the missing context.

• Is eBPF always the answer?

  It’s tempting to rewrite everything in eBPF, but is it always necessary? Dynatrace takes a “tactical” approach. Forcing eBPF onto legacy bare-metal systems with old kernels creates a maintenance nightmare. The argument here is for a hybrid model: use eBPF only where the environment (like Kubernetes) is controlled enough to support it safely.

• The “Cross Your Fingers” Deployment

  We deploy network policies in Kubernetes or Istio, but do we actually know what they are doing? There is a frustrating gap in observability: when a connection fails, was it the policy or the network? Right now, most of us are just guessing.

• Security: To block or to listen?

  If a process acts up, should you kill it immediately? Aggressive blocking often causes more problems than it solves, especially if dependencies break. We discuss the alternative: using “honeypots” and fake tokens to let attackers reveal themselves before you take action—learning the behavior rather than just stopping the process.

I’ll leave it at that. Hope you enjoy it 🐝

That was a good starting point, but building useful programs also requires other eBPF features such as maps and helper functions.

The complexity of real applications naturally depends on the problem, but one of the simplest—and also one of the first—examples I built early on was packet rate limiting.

So here comes the new coding lab: https://labs.iximiuz.com/tutorials/ebpf-ratelimiting-dbc12915

I’ve received countless nice messages from people following the labs, and I’m really happy about the positive impact they’re having on the eBPF community.

Still, I’m curious what you think about this:

Best, Teodor 🐝

It’s a simple intro to XDP, how it works, the different modes it can operate in, and what packet information you can access. But of course, we don’t stop there — in the upcoming weeks, we’ll build on these fundamentals and create an XDP packet rate-limiter, a firewall, and an XDP load balancer.

Link: https://labs.iximiuz.com/tutorials/ebpf-xdp-fundamentals-6342d24e

Hope you like it ✌️

Rafael’s story spans from mainframes and operating system internals to maintaining Tracee at Aqua Security, and now, pushing eBPF to its architectural limits at Garnet. Here’s what we covered:

• From CI/CD runtime security to Kubernetes

  Jibril started as a project focused on GitHub Actions runtime security, but as users began deploying it in Kubernetes clusters, the transition was natural. After all, GitHub runners are just virtual machines — Kubernetes simply scales that model across nodes.

• The context-first vision

  From day one, Garnet’s founders had a clear thesis: whoever holds the best context wins. Jibril’s engine was built around this — capturing what’s happening at the system level without caring whether it’s running on GitHub, Kubernetes, or even a toaster.

• A new/unique way to process kernel events

  Unlike traditional runtime security tools like Falco, Tetragon, or Datadog Agent, Jibril doesn’t stream events from kernel to user space. Instead, it uses an in-kernel data query model — treating eBPF maps like a database.
  Rather than flooding user space with raw events, Jibril stores, indexes, and exposes them on-demand through queries. The result: an order of magnitude reduction in CPU and memory usage while maintaining full observability.

• Virtual maps and caching

  To make this model scale, Rafael built what he calls virtual maps — “maps made of maps” — enabling nested lookups and richer data structures entirely in-kernel.
  A userland caching layer further optimizes queries, ensuring repeated lookups don’t re-hit the kernel unless necessary. The outcome is a smooth balance between cadence and performance, with tunable refresh intervals depending on workload.

• Beyond just detection

  Jibril already supports in-kernel enforcement, blocking domains or CIDRs at egress using eBPF — no proxy, no user-space hop.
  For broader cluster-wide blocking, it can also hand off to Cilium to enforce network policies, rather than competing with it.

At the end, there’s a short demo of Jibril — aimed at a more technical audience — showcasing the concepts we discussed throughout our conversation.

I’ll leave it at that — this was one of the most technical and insightful discussions I’ve had about eBPF architecture in a while.

Jibril is shaping up to be a fascinating rethink of how we do runtime security — not by streaming data faster, but by rethinking where and how data lives. 🐝

Today, I’m releasing a new batch of coding labs focused on comparing different eBPF tracing program types such as Tracepoints, Raw Tracepoints, Kprobes, and Fprobes.

And of course, we don’t stop there — I also show you how to make these program types portable, discuss the challenges of depending on BTF, and explain how to design truly portable eBPF programs.

Link: https://labs.iximiuz.com/skill-paths/core-ebpf-program-e25e0f1c

Hope you like it ✌️

Starting CloudChirps back in 2022

My technical writing journey goes back almost 4 years, to when I published my first Medium post. And it wasn’t even about eBPF…

At the time, I had just moved to Germany to finish my Bachelor’s degree at TU Berlin.

I was working on a lot of cool projects — like a farming robot and some Kubernetes-related stuff.

At some point, I thought it might be cool to have a diary or a blog to document all these projects. It could also benefit me in the long run, especially since I saw how others were thriving by sharing their work.

I still remember writing those first few lines and realizing how much I didn’t know. It made me think — there were countless ways I could have approached projects differently, and so many design decisions I hadn’t thought through carefully enough.

Writing forced me to rethink them.

So I started sharing the different projects I worked on, along with whatever else interested me in my free time — computer was my buddy 24/7, so yeah...

For about two years, Medium was my go-to platform, and I was actually doing better than I expected.

By the way, if you’re wondering about that steep growth just before 2024 — it’s because some of my posts were selected for Medium’s Boost program, which foster authentic and unique posts on other people’s dashboards.

Going away from Medium at the end of 2024

In my opinion back then, Medium had gotten a lot worse for many writers in the AI era.

The platform just couldn’t filter or deter AI-generated content effectively, and it started to feel more like a competition over who could post more often rather than who could create valuable work.

And while I did see a lot of traffic on my posts, I just didn’t enjoy scrolling through the dashboard anymore — out of 10 posts I saw, more than half were clickbaits with practical non-sense and false assumptions.

I don’t mean to discourage any writers or throw shade on the people who post there — many share amazing stuff; it’s just hard to find.

I had a feeling others would start to feel the same. So I made a bold move and switched to Substack. Starting from zero, again…

I wouldn’t say Substack has less AI-generated content, but what makes the difference is the ability to reach readers directly — and I think they appreciate that more personal approach, with less “AI friction,” since the posts arrive straight in their inbox.

And I think this will also be the way forward for any social media platform.

LinkedIn is great-ish, Medium is great-ish, and so are others — but for people who want to avoid all the noise just to find something valuable, it’s becoming a bit too much.

This in a way also makes it harder for you to reach new subscribers, because each one of them thinks twice before subscribing. No one likes trash in their inbox.

But that’s actually not a bad thing at all. Those who subscribe truly want to hear from you, and you don’t have to worry about casual followers who’d probably unsubscribe later anyway.

During that time I also finished my Bachelor Degree at TU Berlin and pursued my Master Degree at the Computer Science Faculty in Slovenia, Ljubljana and later finishing it in Vienna at TU Wien.

Besides my studies, I also started working as an intern at a research laboratory.

I surrounded myself with people at the university who had both diverse industry experience and a strong interest in researching next-generation technologies.

During one of the courses, my professor briefly mentioned the problem of cold starts in FaaS environments.

In short, it’s the time you have to wait for the FaaS platform to spawn a container behind the scenes to serve your request — think of it, like running docker run, which usually takes about a second or so.

So I started looking around the web, trying to understand the problem better and the following Cloudflare article popped out to me about Eliminating cold starts with Cloudflare Workers.

So I pinged Cloudflare maintainers on Discord, without much success — figuring out later that the code that performs the “pre-warmup“ of the container isn’t open-source.

So I thought — if this ain’t open-source, why not try to do it using Docker containers and some “other technology”.

The problem was clear to me that I should be able to capture the 1st TLS packet and somehow spawn the container, while the handshake is still occuring — consequently reducing cold start.

And I ended seeing the eBPF word online more often, as a way to capture and parse network packets. And not really quickly, but after some things started to conceptually make sense.

Although I didn’t knew much about eBPF, but according to the xdp-project/xdp-tutorial GitHub repository that I was able to find, capturing and parsing network traffic was possible using eBPF/XDP.

I eventually ended-up finishing the project above (which I could only post much later due to the research publication constraints) and if you’re interested - here’s the link:

Why am I mentioning this?

Because exactly then was the time, when eBPFChirp idea was born.

Starting eBPFChirp in mid-2024

When I was tackling the problem of cold starts back then, hardly anyone was writing about eBPF — except for Bill Mulligan and a few folks speaking about it at conferences.

Information was scarce. Sometimes, I’d even end up reading Linux kernel patches just to wrap my head around certain concepts.

I just couldn’t find a single blog that explained eBPF in a simple, “kid-like” way — something that said, “Hey, this is eBPF, here’s how it works, and here’s how you can use it.”

I wish I could say my newsletter could be read by a kid — but that’s kinda hard when it also needs to be appealing for both beginners and advanced eBPF users. So yeah, it’s a bit of a double-edged sword.

So I guess it was the hard way — but also an exciting one, because writing about something few others do is what sets me apart and gives me joy, knowing I can bring real value.

Going through different open-source projects, rewriting them, tweaking a few lines of code and observed what was happening was getting me better and better in understanding the ins-and-outs.

But at the same time, I also wanted to build on all the mistakes I made back when I was writing on Medium. Things like:

• Improving post titles to give readers a clear idea of what to expect

• Design custom images with warm colors

• Preferring short paragraphs over long unformatted content

• Breaking down tech buzzwords

And the list goes on...

I also had to rethink how to market and distribute my content, because let’s be honest — readers rarely share a post after reading it, and it’s kind of impossible to expect a newsletter to grow organically on its own. Especially when you start from zero.

For that matter, I see LinkedIn as a great platform to connect with people — and I wanted to capture and redirect as many of them as possible to my newsletter.

One might say, the number of followers actually made it easier for me to distribute and reach other people — but it was actually reposting eBPFChirp blog posts on Linkedin that help me grow it.

I’m still working on the marketing side of blogging and learning something new every week — whether it’s:

• Writing more compelling LinkedIn posts

• Collaborating with other authors

• Approaching people at conferences and talking about eBPF

• Figuring out which eBPF topics people are most interested in

• Stepping out of my comfort zone to start the eBPFChirp FM podcast

• Speaking at meetups and conferences

…and the list goes on.

And over time, a lot of seemingly unrelated things found their common thread:

• Running eBPFChirp FM Podcasts helped me build confidence speaking in a foreign language and presenting at conferences.

• Helping others grow also helped me grow my own brand.

• Writing pushed me to simplify complex ideas — it’s one thing to understand eBPF deeply, and another to explain it clearly.

• And it opened new doors — invitations to conferences, collaborations with open-source maintainers, and even new business opportunities.

I also recently became a Fellow of the eBPF Foundation, but what felt even more fulfilling to me was being listed as a judge for the eBPF Hackathon, alongside some truly renowned names in the eBPF community.

All of these things fulfill me in many ways, but I’m still far from where I want to be.

Present Situation

Today, I’m really happy with how eBPFChirp is evolving — every month, around 50 to 100 new subscribers join, and it’s grown to the point where I don’t even keep track anymore.

Some read often, some less — but it’s an incredible feeling knowing people want my posts delivered straight to their inbox whenever I publish.

Lately, I’ve also been thinking a lot about how to monetize it — mostly because of how much energy it takes. Not in a bad way, but, well… something has to pay the bills, you know 😅

I’m still far from that point, but I’ve started to allow myself to visualize a future where eBPFChirp becomes something I do full-time. It’s not forbidden to dream, right?

It’s almost 3 AM, and I’m wrapping up this reflection — but hey, this is what I love to do.

Best, Teodor

• From inference to insight
  Before Oligo, Avi worked at Deci AI, optimizing model inference speed. There, he realized something crucial — performance isn’t just about models; it’s also about how well you understand and leverage the system it runs on.

• The confinement challenge
  Imagine a Python model that should only do math, but could also spawn a subprocess or access the network. How do you confine it safely?

• Discovering eBPF
  His early experiments with DTrace were too slow and invasive for production, so when eBPF matured, he rebuilt his secimport prototype — and found a scalable way to trace and enforce what code can (and can’t) do in real time.

• Beyond observability
  Avi’s big insight: eBPF isn’t just for monitoring. Combined with Linux Security Modules (LSM) and KRSI, it can actively stop malicious behavior before it completes — for example, blocking a rogue pickle.load() before it spawns a shell.

• Language-aware security
  At Oligo, Avi’s team extended this concept across languages — Python, Java, Node, .NET, PHP — extracting application-level context straight from production without user-space overhead.

• From CVEs to context
  Instead of flagging every potential vulnerability, Oligo maps which functions actually run in production, reducing noise and focusing developer effort where it matters most.

• The AI connection
  We also discussed how AI agents could soon operate eBPF — dynamically tuning kernel parameters or deploying probes on demand, creating adaptive, self-healing systems.

• Looking ahead
  Avi sees a future where security tooling merges with intelligence — where production data directly informs code fixes, and AI uses eBPF to keep systems resilient in real time.

🐝 I’ll leave it there — hope you enjoy the conversation.