---
title: "BPF"
description: "6 posts about BPF, summarised, each linking to the original."
---

# BPF
> 6 posts about BPF, summarised, each linking to the original.

## Articles

### [KubeVirt, VSOCK, and eBPF: who does what?](https://yomu.fyi/post/kubevirt-vsock-and-ebpf-who-does-what.md)
- Company: [Boxcompute](https://yomu.fyi/company/boxcompute.md)
- Author: boxy
- Published: Sep 15, 2026
- Type: Explainer

KubeVirt, 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.


### [Modernizing the Meta Ads Service With an Open-Source Kernel Scheduler](https://yomu.fyi/post/modernizing-the-meta-ads-service-with-an-open-source-kernel-scheduler.md)
- Company: [Meta](https://yomu.fyi/company/meta.md)
- Published: Jul 13, 2026
- Type: Problem & solution

Meta’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.


### [JIT WireGuard](https://yomu.fyi/post/jit-wireguard.md)
- Company: [Fly.io](https://yomu.fyi/company/fly-io.md)
- Published: Mar 12, 2024
- Type: Problem & solution

Fly.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.


### [IPv6 WireGuard Peering](https://yomu.fyi/post/ipv6-wireguard-peering.md)
- Company: [Fly.io](https://yomu.fyi/company/fly-io.md)
- Published: Dec 23, 2020
- Type: Announcement

Fly.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.


### [Incoming! 6PN Private Networks](https://yomu.fyi/post/incoming-6pn-private-networks.md)
- Company: [Fly.io](https://yomu.fyi/company/fly-io.md)
- Published: Dec 8, 2020
- Type: Announcement

Fly.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.


### [BPF, XDP, Packet Filters and UDP](https://yomu.fyi/post/bpf-xdp-packet-filters-and-udp.md)
- Company: [Fly.io](https://yomu.fyi/company/fly-io.md)
- Published: Oct 20, 2020
- Type: Explainer

Deploying 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.