netdev - Configurable XDP Generic Packet Headroom to avoid SKB re-allocation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <d02c6db8-6bd8-48b0-b235-cf132d42057f@tk154.de>
Date: Wed, 18 Jun 2025 17:03:49 +0200
From: Til Kaiser <mail@...54.de>
To: Alexei Starovoitov <ast@...nel.org>,
 Daniel Borkmann <daniel@...earbox.net>, "David S. Miller"
 <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
 Jesper Dangaard Brouer <hawk@...nel.org>,
 John Fastabend <john.fastabend@...il.com>
Cc: netdev@...r.kernel.org, bpf@...r.kernel.org
Subject: Configurable XDP Generic Packet Headroom to avoid SKB re-allocation

Hello,

While investigating performance issues with XDP in generic mode, I 
noticed frequent SKB re-allocations due to insufficient headroom, an 
issue also discussed in earlier proposals such as [1] and [2].
Currently, netif_receive_generic_xdp() checks against a fixed 
XDP_PACKET_HEADROOM (256 Bytes) [3].

I would like to propose making the generic XDP headroom configurable per 
interface via a new member in struct net_device, e.g., 
xdp_generic_headroom initialized to XDP_PACKET_HEADROOM at device 
allocation. The user can change its value via Netlink and/or sysfs 
before the XDP Generic program is attached to the interface, and 
netif_receive_generic_xdp() then uses this instead of the hardcoded 
headroom. When the XDP Generic program is detached, it is automatically 
reset to the default XDP_PACKET_HEADROOM value to avoid conflicts with 
future programs.

This would allow users to avoid unnecessary SKB re-allocations if they 
know their program’s headroom requirements in advance.
Would this be a viable alternative? I’d be happy to prototype a patch.

Kind regards
Til

[1] 
https://patchwork.kernel.org/project/netdevbpf/patch/039064e87f19f93e0d0347fc8e5c692c789774e6.1647630686.git.lorenzo@kernel.org
[2] 
https://patchwork.kernel.org/project/netdevbpf/patch/20220314102210.92329-1-nbd@nbd.name
[3] 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/net/core/dev.c?h=v6.15.2#n5279