On Mon, Jan 12, 2026 at 07:08 PM -08, Jakub Kicinski wrote: > On Sat, 10 Jan 2026 22:05:14 +0100 Jakub Sitnicki wrote: >> This series is split out of [1] following discussion with Jakub. >> >> To copy XDP metadata into an skb extension when skb_metadata_set() is >> called, we need to locate the metadata contents. > > "When skb_metadata_set() is called"? I think that may cause perf > regressions unless we merge major optimizations at the same time? > Should we defer touching the drivers until we have a PoC and some > idea whether allocating the extension right away is manageable or > we are better off doing it via a kfunc in TC (after GRO)? > To be clear putting the metadata in an extension right away would > indeed be much cleaner, just not sure how much of the perf hit we > can optimize away..
Good point. I'm hoping we don't have to allocate from skb_metadata_set(), which does sound prohibitively expensive. Instead we'd allocate the extension together with the skb if we know upfront that metadata will be used. Things took an unexpected turn and I'm figuring this out as I go. Please bear with me :-) Here are my thoughts: 1) The driver changes do clean up the interface, but you're right that it's premature churn if the approach changes. If the skb extension approach doesn't pan out, we're ready to fall back to headroom-based storage. 2) How do we handle CONFIG_SKB_EXTENSIONS=n? Without extensions, reliable metadata access after L2 encap/decap would require patching skb_push/pull call sites—or we declare the feature unsupported without CONFIG_SKB_EXTENSIONS=y. 3) When skb extensions are enabled, asking users to attach TC BPF progs to call a kfunc to all devices the skb goes through before L2 encap/decap is impractical. The extension alloc/move needs to be baked into the stack. I'll focus on getting a PoC together next. Stay tuned. Thanks, -jkbs
