Thrice the charm: an skb extension for BPF metadata#

Jakub Sitnicki and Andrej Stender

Why: Carrying custom per-packet metadata between BPF hooks is a recurring blocker for anything building policy or identity into the datapath (service mesh, per-connection labels, tenant tags). This is the third attempt at solving it and the write-up includes why the previous designs failed.

What: A proposal to give BPF programs a place to store data whose lifetime is the skb's, outside the narrow scope where XDP/skb metadata works today.

How: Two candidate mechanisms are compared — one available today, one still on the drawing board — from the point of view of the BPF networking hooks and their overhead, along with the rejected alternatives (extending skb metadata lifetime guarantees, BPF local storage) and why they didn't work. The skb-extension mechanics get the most attention: compiling out unused extensions, and the extra hot-path allocation that skb extensions currently imply. Ends on open user-API questions. (From abstract only.)

Where applicable: Anything BPF-based in the kernel datapath; this is upstream design discussion, so the value is in knowing which way the API is likely to land before building on the current workarounds.