Re: [PATCH net-next 1/8] net: add tx_extra_headroom and LL_ALLOC_SPACE()

[Willem de Bruijn <willemdebruijn.kernel@gmail.com>]

Tianyi Gao wrote:
> Hi Stephen,
> 
> Thanks for the invaluable and detailed review.
> 
> On Sun, 8 Nov 2026 19:08:31 -0800, Stephen Hemminger wrote:
> > Since the motivating case is XDP, the mechanism should let the XDP program
> > ask for the padding it needs, rather than making the operator translate
> > the program's requirement into a device setting by hand.
> 
> The series started from David Keogh's TC egress case, as described in
> the RFC [1] and in the first paragraph of the v1 cover letter. The veth
> XDP case came later, when I found that the same field also avoids the
> copy for generic XDP on veth.
> 
> > Your own reply already works this out:
> >
> > > - XDP on a veth peer: veth_xdp_set() and generic_xdp_install() can
> > >   increase the headroom of the peer to XDP_PACKET_HEADROOM on attach
> > >   and reset it on detach.
> >
> > That is the mechanism, and it needs no uapi, no operator arithmetic, and
> > no stale state. I would rather see it implemented for the cases it covers
> > than add a permanent uapi that removes the incentive to do so.
> 
> Agreed. For this case, I plan to move to this in v2. When an XDP program
> is attached to a veth device, tx_extra_headroom of the peer is set to
> XDP_PACKET_HEADROOM.
> 
> > On the argument that program-side declaration is itself new uapi, and that
> > the labeled device is often not the device the skb was allocated on:
> > granted for the general TC egress case.
> 
> For TC egress, the kernel does not know at attach time how many bytes
> the program pushes. Only the program, or the software that loads it,
> knows. Attach-time propagation works for XDP because XDP_PACKET_HEADROOM
> is a fixed value.
> 
> Since we both agree that auto-tuning has real problems, a narrow UAPI,
> such as a BPF-side declaration, seems unavoidable for TC egress. The
> program declares the headroom that it needs through this UAPI. The
> initial plan is a BTF decl_tag, as Dragos Tatulea suggested on the RFC
> [2]. On attach, the kernel increases tx_extra_headroom of the device
> that the program is attached to.
> 
> > Which leaves the genuinely hard case, the one you describe at Cloudflare: a
> > service in a netns sends through a veth pair, the host forwards to the
> > uplink, and a TC egress program there encapsulates, after ip_rcv_core()
> > has orphaned the skb so the allocating device cannot be identified. If
> > that is the real residue, make it the problem being solved and argue for
> > the narrowest mechanism that solves it.
> 
> This case only came up after I started to look at in-kernel approaches,
> because the general IFLA_TX_EXTRA_HEADROOM UAPI already solves it. It is
> not a new case, and it is not uncommon. Cilium, Flannel and Calico use a
> tunnel by default [3][4][5], so the device that encapsulates is not the
> device that allocated the skb.

I have some hope that if there is sufficient reason, this backlinking
to the originating netdev (or socket?) can eventually be addressed as
well. Rather than work around it.

The skb_orphan and iif issues are well know. But not set in stone.