Epilogue - The Road Ahead

The book opened with a promise: that the kernel’s packet path is learnable from first principles, that eBPF makes it programmable, and that Rust makes that programming safe enough to trust. Sixteen chapters later, the promise has a shape. You have built the packet path, the eBPF virtual machine and its verifier, the map contract, the XDP and tc data planes, the socket layer, the Kubernetes service model, and a complete service-mesh data path - each one explained, each one measured, each one built from primitives you can now define from memory.

What You Now Know (and Can Derive)

The real inventory is not the topics; it is the derivations. You can now answer, from models rather than memory:

• Why a packet costs what it costs, and where eBPF hooks can cut the cost (Chapters 1, 7).
• Why the verifier rejects a program, and how to shape a program so it passes (Chapters 2, 14).
• Why a map type is right for an access pattern, and how the kernel and userspace sides of that contract stay in sync (Chapter 4).
• Why XDP runs before the stack and tc after, and what each placement buys you (Chapters 5-6).
• Why a sockmap redirect avoids a round trip through userspace, and how the socket layer makes it correct (Chapter 8).
• Why kube-proxy was the bottleneck, and how Cilium’s eBPF data plane replaced it (Chapters 10-11).
• Why eBPF is both the safest way to extend the kernel and a powerful attack surface, and how the kernel fences both sides (Chapter 15).

The book’s thesis - stated in the foreword and proven by the capstone - is that the kernel is not a black box; it is the next platform, and you now speak its language.

Where the Discipline Goes From Here

Every chapter ends with the same implicit instruction: apply this to something real. The natural next steps, in order of leverage:

1. Run the capstone, then break it. The Chapter 16 service-mesh data path is deliberately minimal. Add an L7 filter, a second backend, a latency histogram - and watch the verifier and the ring buffer tell you exactly where your design is too clever (Chapters 4-5, 14).
2. Trace something you run every day. Pick a process you care about and write an Aya program that counts its system calls, its TCP retransmits, or its page faults. The tracing skills of Chapters 7 and 9 are the fastest way to make eBPF second nature.
3. Read the kernel source. The hooks you used are a few hundred lines in net/core/dev.c, net/socket.c, and kernel/bpf/*.c. The model from Chapters 1-2 makes those files readable; the files will sharpen the model.
4. Contribute to Aya or Cilium. Both projects are welcoming, both are written (increasingly) in Rust, and both reward exactly the skills this book practices: verifier-friendly programs, careful map design, and userspace control planes with real error handling.
5. Teach it. The strongest test of a model is explaining it to someone else - on a whiteboard, to a mentee, or in the interview itself.

The Data Path, One Last Time

You are in the room. The interviewer asks, “Design a service-mesh data path for a Kubernetes cluster.” You draw the diagram from Chapter 16: an XDP program hashing packets to backends, sockmap programs redirecting sockets in the kernel, a ring buffer shipping events to a Hubble-style observer, and a Rust userspace control plane that programs all of it. You name the hook points and the map types. You say why there are no copies and no userspace round trips on the hot path. You volunteer the tradeoffs: XDP cannot parse L7, sockmap does not help UDP as much as TCP, the verifier caps your program size, and the control plane must be exactly as careful as any distributed system.

Then you say the sentence this book has been practicing: “Let me show you the code and the cluster.”

Good luck - and go move some packets.