[bpf-next,v3] bpf: cpumap: report queue_index to xdp_rxq_info

[bpf-next,v3] bpf: cpumap: report queue_index to xdp_rxq_info

[saiaunghlyanhtet]

When packets are redirected via cpumap, the original queue_index
information from xdp_rxq_info was lost. This is because the
xdp_frame structure did not include a queue_index field.

This patch adds a queue_index field to struct xdp_frame and ensures
it is properly preserved during the xdp_buff to xdp_frame conversion.
Now the queue_index is reported to the xdp_rxq_info.

Resolves the TODO comment in cpu_map_bpf_prog_run_xdp().

Signed-off-by: saiaunghlyanhtet <saiaunghlyanhtet2003@gmail.com>
---
 include/net/xdp.h   | 2 ++
 kernel/bpf/cpumap.c | 2 +-
 kernel/bpf/devmap.c | 1 +
 net/core/xdp.c      | 1 +
 4 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/net/xdp.h b/include/net/xdp.h
index aa742f413c35..feafeed327a2 100644
--- a/include/net/xdp.h
+++ b/include/net/xdp.h
@@ -303,6 +303,7 @@ struct xdp_frame {
 	struct net_device *dev_rx; /* used by cpumap */
 	u32 frame_sz;
 	u32 flags; /* supported values defined in xdp_buff_flags */
+	u32 queue_index;
 };
 
 static __always_inline bool xdp_frame_has_frags(const struct xdp_frame *frame)
@@ -421,6 +422,7 @@ int xdp_update_frame_from_buff(const struct xdp_buff *xdp,
 	xdp_frame->metasize = metasize;
 	xdp_frame->frame_sz = xdp->frame_sz;
 	xdp_frame->flags = xdp->flags;
+	xdp_frame->queue_index = xdp->rxq->queue_index;
 
 	return 0;
 }
diff --git a/kernel/bpf/cpumap.c b/kernel/bpf/cpumap.c
index 04171fbc39cb..f5b2ff17e328 100644
--- a/kernel/bpf/cpumap.c
+++ b/kernel/bpf/cpumap.c
@@ -195,7 +195,7 @@ static int cpu_map_bpf_prog_run_xdp(struct bpf_cpu_map_entry *rcpu,
 
 		rxq.dev = xdpf->dev_rx;
 		rxq.mem.type = xdpf->mem_type;
-		/* TODO: report queue_index to xdp_rxq_info */
+		rxq.queue_index = xdpf->queue_index;
 
 		xdp_convert_frame_to_buff(xdpf, &xdp);
 
diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
index 2625601de76e..7e8bfac4ca05 100644
--- a/kernel/bpf/devmap.c
+++ b/kernel/bpf/devmap.c
@@ -348,6 +348,7 @@ static int dev_map_bpf_prog_run(struct bpf_prog *xdp_prog,
 
 		xdp_convert_frame_to_buff(xdpf, &xdp);
 		xdp.txq = &txq;
+		rxq.queue_index = xdpf->queue_index;
 		xdp.rxq = &rxq;
 
 		act = bpf_prog_run_xdp(xdp_prog, &xdp);
diff --git a/net/core/xdp.c b/net/core/xdp.c
index fee6d080ee85..29f0b5ddb39e 100644
--- a/net/core/xdp.c
+++ b/net/core/xdp.c
@@ -606,6 +606,7 @@ struct xdp_frame *xdp_convert_zc_to_xdp_frame(struct xdp_buff *xdp)
 	xdpf->metasize = metasize;
 	xdpf->frame_sz = PAGE_SIZE;
 	xdpf->mem_type = MEM_TYPE_PAGE_ORDER0;
+	xdpf->queue_index = xdp->rxq->queue_index;
 
 	xsk_buff_free(xdp);
 	return xdpf;
-- 
2.52.0

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

[Toke Høiland-Jørgensen]

saiaunghlyanhtet <saiaunghlyanhtet2003@gmail.com> writes:

> When packets are redirected via cpumap, the original queue_index
> information from xdp_rxq_info was lost. This is because the
> xdp_frame structure did not include a queue_index field.
>
> This patch adds a queue_index field to struct xdp_frame and ensures
> it is properly preserved during the xdp_buff to xdp_frame conversion.
> Now the queue_index is reported to the xdp_rxq_info.
>
> Resolves the TODO comment in cpu_map_bpf_prog_run_xdp().
>
> Signed-off-by: saiaunghlyanhtet <saiaunghlyanhtet2003@gmail.com>

This exact patch was submitted before by Lorenzo[0] and was rejected
with the argument that we shouldn't be adding more fields to xdp_frame
in an ad-hoc manner, but rather wait until we have a more general
solution.

-Toke

[0] https://lore.kernel.org/r/1a22e7e9-e6ef-028f-dffa-e954207dc24d@redhat.com

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

[Sai Aung Hlyan Htet]

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?

-Sai

On Wed, Jan 14, 2026 at 7:53 PM Toke Høiland-Jørgensen <toke@kernel.org> wrote:
>
> saiaunghlyanhtet <saiaunghlyanhtet2003@gmail.com> writes:
>
> > When packets are redirected via cpumap, the original queue_index
> > information from xdp_rxq_info was lost. This is because the
> > xdp_frame structure did not include a queue_index field.
> >
> > This patch adds a queue_index field to struct xdp_frame and ensures
> > it is properly preserved during the xdp_buff to xdp_frame conversion.
> > Now the queue_index is reported to the xdp_rxq_info.
> >
> > Resolves the TODO comment in cpu_map_bpf_prog_run_xdp().
> >
> > Signed-off-by: saiaunghlyanhtet <saiaunghlyanhtet2003@gmail.com>
>
> This exact patch was submitted before by Lorenzo[0] and was rejected
> with the argument that we shouldn't be adding more fields to xdp_frame
> in an ad-hoc manner, but rather wait until we have a more general
> solution.
>
> -Toke
>
> [0] https://lore.kernel.org/r/1a22e7e9-e6ef-028f-dffa-e954207dc24d@redhat.com

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

[Toke Høiland-Jørgensen]

Sai Aung Hlyan Htet <saiaunghlyanhtet2003@gmail.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

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

[Sai Aung Hlyan Htet]

On Wed, Jan 14, 2026 at 8:39 PM Toke Høiland-Jørgensen <toke@redhat.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
>
> (Also, please don't top-post on the mailing lists)
>
> -Toke
>

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?

- Sai

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

[Toke Høiland-Jørgensen]

Sai Aung Hlyan Htet <saiaunghlyanhtet2003@gmail.com> writes:

> On Wed, Jan 14, 2026 at 8:39 PM Toke Høiland-Jørgensen <toke@redhat.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
>>
>> (Also, please don't top-post on the mailing lists)
>>
>> -Toke
>>
>
> 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 :)

-Toke

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

[Sai Aung Hlyan Htet]

On Wed, Jan 14, 2026 at 9:34 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote:


> >
> > 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 :)
>
> -Toke
>

Thanks. I will follow the discussion.

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

[Jesper Dangaard Brouer]

On 14/01/2026 13.33, Toke Høiland-Jørgensen wrote:
> Sai Aung Hlyan Htet <saiaunghlyanhtet2003@gmail.com> writes:
> 
>> On Wed, Jan 14, 2026 at 8:39 PM Toke Høiland-Jørgensen <toke@redhat.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

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

[Sai Aung Hlyan Htet]

On Wed, Jan 14, 2026 at 10:30 PM Jesper Dangaard Brouer <hawk@kernel.org> wrote:
>
>
>
>
> On 14/01/2026 13.33, Toke Høiland-Jørgensen wrote:
> > Sai Aung Hlyan Htet <saiaunghlyanhtet2003@gmail.com> writes:
> >
> >> On Wed, Jan 14, 2026 at 8:39 PM Toke Høiland-Jørgensen <toke@redhat.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