| 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
| ||
|
Message-ID: <87bjiw1l0v.fsf@toke.dk> Date: Wed, 14 Jan 2026 12:38:56 +0100 From: Toke Høiland-Jørgensen <toke@...hat.com> To: Sai Aung Hlyan Htet <saiaunghlyanhtet2003@...il.com> Cc: bpf@...r.kernel.org, Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, John Fastabend <john.fastabend@...il.com>, netdev@...r.kernel.org, Jesper Dangaard Brouer <hawk@...nel.org>, Lorenzo Bianconi <lorenzo.bianconi@...hat.com> Subject: Re: [bpf-next,v3] bpf: cpumap: report queue_index to xdp_rxq_info Sai Aung Hlyan Htet <saiaunghlyanhtet2003@...il.com> writes: > Sorry. I did not know it as this is my first time contribution, and > did not check it. > > What about introducing a structured metadata extension area between > xdp_frame and BPF metadata in packet headroom? > > Below is the example memory layout: > Current (after redirect): > [xdp_frame 32B][BPF metadata][unused headroom][data]→ > > Proposed: > [xdp_frame 32B][kernel_metadata 48B][BPF metadata][unused headroom][data]→ > > But, the problem that comes to my mind while thinking about this > solution is that > additional 48 bytes of headroom beyond the 32-byte xdp_frame would be consumed. > WDYT? Yeah, this has been discussed as well :) See: https://netdevconf.info/0x19/sessions/talk/traits-rich-packet-metadata.html Which has since evolved a bit to these series: https://lore.kernel.org/r/20260105-skb-meta-safeproof-netdevs-rx-only-v2-0-a21e679b5afa@cloudflare.com https://lore.kernel.org/r/20260110-skb-meta-fixup-skb_metadata_set-calls-v1-0-1047878ed1b0@cloudflare.com (Also, please don't top-post on the mailing lists) -Toke
Powered by blists - more mailing lists