Session

After a few months of pause, we’re taking another stab at giving BPF users a place to store custom data that lives and dies with the skb.

We’ll start with a recap of what we’ve established about the existing XDP/skb metadata feature:

• What is the scope, the BPF hooks and network stack paths, where users can reliably access the metadata? Under what conditions does it get wiped?
• What is the contract with the network drivers?

From there we’ll look at two ways to store skb-associated BPF metadata outside of where XDP/skb metadata is supported, one available today and one still on the drawing board:

1. Work around that uses a BPF map as a side-stash
2. A BPF metadata buffer embedded in an skb extension chunk (RFC patch set coming)

We’ll compare what the interface looks like from the PoV of BPF networking hooks, and what overhead users can expect from each approach.

To round out the picture, we’ll also cover the alternatives that didn’t pan out, like extending skb metadata lifetime guarantees and adding BPF local storage, and explain where those designs failed.

Next we’ll focus on skb extensions themselves and two aspects of their current implementation that affect how well they can carry BPF metadata, along with how we might improve the status quo: the challenges of compiling out unneeded extensions, and every network stack developer’s worst nightmare, the extra memory allocation on the hot path.

We’ll wrap up with considerations for the user API for BPF metadata access, going over questions like:

• Is a socket API extension, such as a new socket option or cmsg type, necessary?
• How can users exchange BPF metadata today and what are the limitations?
• How can we map the contents of BPF metadata to L7 protocol abstractions (streams, requests)?