r/eBPF

When testing our eBPF agent, I don’t always get the same experience as our users, especially in performance critical sections. I realize that the benchmark test suite isn’t always enough, because user’s environments can be completely different from our benchmarks.

My goal was to gather eBPF metrics based on the user’s usage and quickly answer questions about why things are slow (improve MTTR). To do this, I wanted:

1. Record perf/usage counters in the kernel to show how that particular feature is being used.
2. Performance is essential, as our metrics collection will be in the kernel.
   1. So I cannot use ring buffers for sending messages from the kernel to userspace for the above-mentioned counters.
   2. I didn’t want any spin locks or shared maps, or even LRU caches.
3. I wanted metrics collection to be “on” always for obvious reasons.
4. I wanted the metrics to be a rolling window instead of a counter (more on this later).

Here is a post https://naveensrinivasan.com/posts/2026-08-02-measuring-an-ebpf-cache-without-leaving-the-kernel/

I want to hear if others have better ways to measure this.

This is not another AI generated post.

Hi Reddit,

DDoS attacks are becomeing larger and cheaper to launch, so we work on a scalable open source solution to mitigate them.

Tempesta xFW's core is XDP and TC eBPF programs implementing volumetric DDoS filtering. A user-space daemon handles gRPC requests from CLI tool or WebAPI (via C library).

It supports two packet-path architectures:

• host-based protection, such as CDN edge or on-premises application delivery controller (ADC) cases, where the host is a TCP connection endpoint. This is good for protecting a local web or DNS server.

• router-based protection, such as ISP, hosting, or IaaS provider cases, where the host routes IP packets to protected servers or networks.

Router-based deployment can be always-on/pass-through or on-demand/redirection protection. In the later case, a node may not "see" normal clean traffic and may receive only traffic containing a DDoS attack. Also, the node may receive only client-to-server traffic, as in direct server return (DSR) or some traffic scrubbing scenarios. In this mode a DDoS sensor and mitigation controllers are typically needed.

Traffic performance metrics are exported in Prometheus format.

DDoS incidents are aggregated per source IP and logged to Clickhouse for analysis.

A dry-run (evaluation) - mode allows you to observe all reported incidents and metrics without blocking traffic..

Single Xeon Gold 6348 with ConnectX-6 dual 100Gbps reach 196Mpps and 176Gbps of filtering capacity.

• GitHub repository
• documentation
• performance benchmarks
• Netdev 0x1a talk