[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e0901356-ef48-4652-9ad4-ff85ae07d83a@kernel.org>
Date: Tue, 21 Oct 2025 11:37:00 +0200
From: Jesper Dangaard Brouer <hawk@...nel.org>
To: Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa@...il.com>, ast@...nel.org,
daniel@...earbox.net, davem@...emloft.net, kuba@...nel.org,
john.fastabend@...il.com, sdf@...ichev.me, andrii@...nel.org,
martin.lau@...ux.dev, eddyz87@...il.com, song@...nel.org,
yonghong.song@...ux.dev, kpsingh@...nel.org, haoluo@...gle.com,
jolsa@...nel.org
Cc: netdev@...r.kernel.org, bpf@...r.kernel.org,
linux-kernel@...r.kernel.org, skhan@...uxfoundation.org,
david.hunter.linux@...il.com, khalid@...nel.org,
linux-kernel-mentees@...ts.linuxfoundation.org
Subject: Re: [PATCH bpf-next v2] bpf/cpumap.c: Remove unnecessary TODO comment
On 20/10/2025 19.02, Mehdi Ben Hadj Khelifa wrote:
> After discussion with bpf maintainers[1], queue_index could
> be propagated to the remote XDP program by the xdp_md struct[2]
> which makes this todo a misguide for future effort.
>
> [1]:https://lore.kernel.org/all/87y0q23j2w.fsf@cloudflare.com/
> [2]:https://docs.ebpf.io/linux/helper-function/bpf_xdp_adjust_meta/
>
> Signed-off-by: Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa@...il.com>
> ---
> Changelog:
>
> Changes from v1:
>
> -Added a comment to clarify that RX queue_index is lost after the frame
> redirection.
>
> Link:https://lore.kernel.org/bpf/d9819687-5b0d-4bfa-9aec-aef71b847383@gmail.com/T/#mcb6a0315f174d02db3c9bc4fa556cc939c87a706
> kernel/bpf/cpumap.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/cpumap.c b/kernel/bpf/cpumap.c
> index 703e5df1f4ef..6856a4a67840 100644
> --- a/kernel/bpf/cpumap.c
> +++ b/kernel/bpf/cpumap.c
> @@ -195,7 +195,10 @@ 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 */
> + /* The NIC RX queue_index is lost after the frame redirection
> + * but in case of need, it can be passed as a custom XDP
> + * metadata via xdp_md struct to the remote XDP program
Argh, saying XDP metadata is accessed via the xdp_md struct is just wrong.
Nacked-by: Jesper Dangaard Brouer <hawk@...nel.org>
> + */
>
> xdp_convert_frame_to_buff(xdpf, &xdp);
>
Powered by blists - more mailing lists