netdev - Re: [bpf-next,v3] bpf: cpumap: report queue_index to xdp_rxq

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-prev] [day] [month] [year] [list]

Message-ID: <CAGF5Uf6AJStzQWw1su245T+epoHENaUpQJgx48YefY6bPSAX1A@mail.gmail.com>
Date: Wed, 14 Jan 2026 23:18:13 +0900
From: Sai Aung Hlyan Htet <saiaunghlyanhtet2003@...il.com>
To: Jesper Dangaard Brouer <hawk@...nel.org>
Cc: Toke Høiland-Jørgensen <toke@...hat.com>, 
	bpf@...r.kernel.org, Alexei Starovoitov <ast@...nel.org>, 
	Daniel Borkmann <daniel@...earbox.net>, John Fastabend <john.fastabend@...il.com>, netdev@...r.kernel.org, 
	Lorenzo Bianconi <lorenzo.bianconi@...hat.com>
Subject: Re: [bpf-next,v3] bpf: cpumap: report queue_index to xdp_rxq_info

On Wed, Jan 14, 2026 at 10:30 PM Jesper Dangaard Brouer <hawk@...nel.org> wrote:
>
>
>
>
> On 14/01/2026 13.33, Toke Høiland-Jørgensen wrote:
> > Sai Aung Hlyan Htet <saiaunghlyanhtet2003@...il.com> writes:
> >
> >> On Wed, Jan 14, 2026 at 8:39 PM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
> >>
> >>> 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
> >>>
>
> Above links are about 100% user defined metadata, that the kernel itself
> have no structural knowledge about.
>
> The RX queue_index (as you wrote in desc[1]) is something that gets lost
> when XDP-redirecting. The series in [0] is about transferring
> properties/info that got lost due to XDP-redirect. Lost info that the
> SKB could be populated with.
>
>   [0]
> https://lore.kernel.org/all/175146824674.1421237.18351246421763677468.stgit@firesoul/
>   - Subj: "[V2 0/7] xdp: Allow BPF to set RX hints for XDP_REDIRECTed
> packets"
>
>   [1]
> https://lore.kernel.org/all/20260114060430.1287640-1-saiaunghlyanhtet2003@gmail.com/
>
>
> >>> (Also, please don't top-post on the mailing lists)
> >>>
>
> Please read Networking subsystem (netdev) process[2]:
>   [2] https://kernel.org/doc/html/latest/process/maintainer-netdev.html
>
>
> >> Thanks for the pointers. It is really great to see this series. One
> >> question: Would adding queue_index to the packet traits KV store be
> >> a useful follow-up once the core infrastructure lands?
> >
> > Possibly? Depends on where things land, I suppose. I'd advise following
> > the discussion on the list until it does :)
> >
>
> Hmm, the "original" RX queue_index isn't super interesting to CPUMAP.
> You patch doesn't transfer this lost information to the SKB.
>
> Information that got lost in the XDP-redirect and which is needed for
> the SKB is RX-hash, hardware VLAN (not inlined in pkts) and RX-
> timestamp. As implemented in [0].
>
> --Jesper
>
>

Thanks for the clarification, Jesper. I see now
that my patch only makes queue_index available in BPF context but doesn't
restore it to the SKB.

Before I invest more time in the wrong direction, I have a few questions
about the proper path forward:

1. Does your RX hints series provide a way to restore queue_index to
   the SKB? If so, would the TODO in kernel/bpf/cpumap.c be
   addressed by that work?

2. If queue_index restoration is not part of the current RX hints series,
   would it be acceptable to add it using the same mechanism you've
   implemented for hash/VLAN/timestamp? I'd be happy to contribute a
   patch following your approach.

3. Alternatively, should I wait for the RX hints infrastructure to land
   and then submit queue_index as a follow-up?

- Sai