Re: [RFC net-next 0/6] net: configurable extra TX headroom for local egress
From: David Woodhouse
Date: Fri Oct 16 2026 - 04:12:58 EST
On Thu, 2026-10-15 at 23:53 +0000, David Keogh wrote:
>
> Measurements (net-next at commit 05b5019b0, veth, 500000 UDP datagrams, a
> 20-byte ip-in-ip push attached at TC egress, only tx_extra_headroom varied):
>
> tx_extra_headroom pskb_expand_head reallocs / 500k
> 0 (off) 500003 (~1 per packet)
> 64 4 (background)
> 128 2 (background)
I remember frowning at this years ago, in the context of PPPoE.
I have the same question I had back then: why, if *every* packet ends
up having to call pskb_expand_head() because it didn't have enough
headroom, does our kernel need to be *told* by userspace that it needs
to expand the allocations?
We gained dev->needed_headroom and ip_tunnel_adj_headroom() since then,
and the kernel doesn't actually need to be told.
You explained why you don't want to use dev->needed_headroom; I don't
have much of an opinion on that front. But if you do want to introduce
a new tx_extra_headroom, could we try really hard to have it auto-
tuning?
Attachment:
smime.p7s
Description: S/MIME cryptographic signature