Tianyi Gao wrote:
On Sat, Nov 07, 2026 at 09:51:07AM -0500, Willem de Bruijn wrote:
quoted
Tianyi Gao wrote:
quoted
From: David Keogh <redacted>
Add a tx_extra_headroom field to struct net_device for that purpose,
Main high level concern is just adding an extra field. What's next,
do we need to add a field extra_extra_headroom?
Thanks for the review.
A user needs more room either in every packet or only in new skbs.
needed_headroom covers the first case and tx_extra_headroom the
second. I do not see a third case.
needed_headroom does not only set the headroom of new skbs. It is also
the minimum that ip_finish_output2() and ip_forward() require of
existing skbs. Raising it for new skbs also raises that minimum. With
XDP on a veth peer and needed_headroom raised to 256, throughput drops
by 2.8% to 5.8% for local TCP and by 4.0% to 20.8% for forwarded
traffic. The cover letter has the detailed analysis. veth also cannot
set needed_headroom from user space today.
pahole on x86_64 (defconfig, net/core/dev.o) shows that the field fills
the 2-byte hole after needed_headroom, so struct net_device does not
grow:
before:
unsigned short needed_headroom; /* 60 2 */
/* XXX 2 bytes hole, try to pack */
/* size: 2688, cachelines: 42, members: 187 */
after:
unsigned short needed_headroom; /* 60 2 */
unsigned short tx_extra_headroom; /* 62 2 */
/* size: 2688, cachelines: 42, members: 188 */
Thanks.
Pushing back on another design choice: the UAPI change. That both cannot be
undone, and is fragile and laborious, requiring manual admin arithmetic.
The RFC patch mentioned two other approaches: explicit headroom requirement
labeling for tc and BPF, and dynamic adjustment of this field whenever a
realloc in the stack is encountered.
They are left for future work. But should those instead be implemented
first? As said, this manual hackery cannot be undone. While in-kernel
mechanisms can be refined and built upon.
It seems to be that this series is trying to address a few related
situations and argues that no single solution fixes all except for manual
adjustment. But likely a combination of the above (and more) will.
This does leave the veth peer to solve, but that does not seem
fundamentally intractable.