BPF is not one hook but a set of attachment points, and each one sees different traffic. This diagram maps XDP, TC, socket-level BPF LSM, and sched_ext so you can pick the layer that can actually enforce your rule.
BPF programs are only as capable as the point where the kernel runs them, so the attachment point decides what a program can observe, modify, or deny. This explainer lays out four layers in the order a packet and a system call meet them: XDP at ingress before the network stack, TC filters after the stack has parsed the packet, socket and BPF LSM hooks at connection and syscall time, and sched_ext at the CPU scheduling layer. It also marks the boundaries those choices create, such as why ordinary XDP and TC filters never see VSOCK traffic and why host-side enforcement has to happen at the socket hook instead.
XDP gives the fastest ingress path but a narrow view, since it runs before the stack has parsed much. Deeper hooks such as BPF LSM and sched_ext see more context but inherit verifier constraints like bounds checks, harder debugging with dropwatch and perf tracing, and policy-lifetime questions. Choose the shallowest layer that can still see and enforce the thing you care about.
The posts behind it
Boxcompute · · ExplainerKubeVirt, VSOCK, and eBPF address different layers, so none replaces the others. KubeVirt adds virtual-machine lifecycle management to Kubernetes, running QEMU in a launcher Pod while KVM uses hardware virtualization features to execute guest code; it does not replace either component. VSOCK provides host–guest communication through a CID-and-port socket address, independently of guest IP networking, but attaching virtio-vsock does not define permitted applications or provide authentication and authorization. For host-enforced control, BPF LSM can use the socket_listen hook to deny unapproved host-side VSOCK listeners before creation, whereas ordinary XDP and TC filters on VM network interfaces do not see VSOCK traffic; this still leaves existing listeners, per-guest permissions, kernel attack surface, policy lifetime, and other virtual devices to address.
Meta · · Problem & solutionMeta’s ads serving fleet processes more than 5 million requests per second, so millisecond-scale latency changes can affect ads relevance and advertiser ROI. During a move from kernel 6.4 with CFS to kernel 6.9, the team observed a latency regression associated with EEVDF and used sched_ext, an upstream BPF-based framework, to encode ads-specific scheduling priorities. The policy soft-partitions CPUs between latency-critical request-path threads and less-sensitive work, adjusts pool sizes with load-based heuristics, and runs as a user-space binary that loads BPF, enabling policy changes without rebuilding or reinstalling the kernel. Initial results were a 28% reduction in ads retrieval p99 latency, 3.28 megawatts of fleet power savings, and a 1.1% increase in weighted ads ranked; two later user-space updates delivered an additional 60% p99 reduction and an 18% decrease in critical-path timeout errors, with iterations shipping in days rather than months.
Fly.io · · Problem & solutionFly.io describes how its gateways provisioned WireGuard peers for flyctl and why the old design became unreliable and slow. NATS delivery losses caused failed provisioning, while CI-generated peers accumulated because gateways never removed them, leaving hundreds of thousands of stale kernel entries that slowed reloads and contributed to kernel panics. The replacement detects handshake-initiation packets with BPF or a WebSockets packet hook, runs enough Noise cryptography to recover the initiator’s public key, then fetches matching peer data over an internal HTTP API and installs it on demand. A rate-limited SQLite cache supports cleanup jobs, and the gateway can use the observed four-tuple to initiate back toward flyctl and accelerate handshakes. After weeks in production, stale peers rounded to none, with faster setup and rebooting that no longer required reloading unused entries.
Fly.io · · AnnouncementFly.io presents WireGuard Peering as a way to connect applications running on its platform privately to AWS, GCP, or other networks, while preserving automatic communication among apps in an organization. Each organization receives a private IPv6 network called a 6PN, with addresses encoding organization, host, and instance identifiers; BPF enforces isolation, and internal DNS resolves app, regional, and peer names. Because WireGuard’s cryptokey routing does not allow overlapping Allowed IPs, Fly swaps the address’s network and host chunks before and after routing, giving the mesh non-overlapping prefixes without changing IPv6 checksums. Users create regional peer configurations with flyctl wireguard create, receiving /120 delegations and organization-specific DNS. The post says this works for database gateways such as an AWS RDS setup, direct app-instance access, and arbitrary services, with connectivity remaining direct between nodes.
Fly.io · · AnnouncementFly.io introduces 6PN, an IPv6 private network intended to let applications in the same organization communicate without public IP addresses, mTLS, or certificates. Each application instance receives an organization-scoped IPv6 address, while per-application internal DNS zones resolve instances, regions, and sibling apps; enabling it requires private_network = true in fly.toml, though the post says it will soon be on by default. Examples show nginx discovering cache shards, Redis binding to fly-local-6pn, and NATS forming a cross-application cluster through internal names. Behind the feature, addresses encode organization, host, and instance identifiers, while BPF programs enforce network isolation and support WireGuard cryptokey routing; a Rust DNS server serves internal records. The stated goal is simple private connectivity with optional user-managed clustering, service discovery, and certificate infrastructure.
Fly.io · · ExplainerDeploying unmodified UDP applications across an anycast edge and worker network is harder than proxying HTTP, because UDP carries no convenient metadata for forwarding the original socket addresses. The initial implementation used userland services, AF_PACKET sockets, and custom proxying, but the post argues that kernel-level packet handling is a better fit than adding and monitoring another service. It explains BPF’s evolution into eBPF, then describes using XDP for fast ingress processing, XDP_REDIRECT around WireGuard limitations, and TC BPF on the worker side; Firecracker tap devices make reply traffic appear as host ingress. The verifier requires bounds checks and debugging benefits from dropwatch and perf-based packet tracing. The result is a beta deployment path for UDP applications on Fly.io.
More like this
AI-DLC is an AI-driven development lifecycle that runs delivery through Inception, Design, and Construction, with specs, steering files, and hooks keeping agents aligned to agreed intent.
Apple Silicon's defining choice is one shared memory pool for CPU, GPU, and Neural Engine. This diagram maps that fabric, the on-package bandwidth it buys, and the scaling limits it imposes.
Antimicrobial resistance surveillance is a layered data architecture: raw reads and demand signals flow in, get normalized into governed tables, and answer plain-language queries. The diagram maps each boundary.
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
One useful email. Unsubscribe anytime.
