On 9/25/25 11:47 AM, Jakub Sitnicki wrote:

On Thu, Sep 25, 2025 at 12:28 PM +01, Mehdi Ben Hadj Khelifa wrote:

quoted

On 9/25/25 11:18 AM, Jakub Sitnicki wrote:

quoted

On Thu, Sep 25, 2025 at 11:54 AM +01, Mehdi Ben Hadj Khelifa wrote:

quoted

On 9/25/25 10:43 AM, Jakub Sitnicki wrote:

quoted

On Tue, Sep 23, 2025 at 10:00 PM +01, Mehdi Ben Hadj Khelifa wrote:

quoted

    This patch series is intended to make a base for setting
    queue_index in the xdp_rxq_info struct in bpf/cpumap.c to
    the right index. Although that part I still didn't figure
    out yet,I m searching for my guidance to do that as well
    as for the correctness of the patches in this series.

What is the use case/movtivation behind this work?

The goal of the work is to have xdp programs have the correct packet RX queue
index after being redirected through cpumap because currently the queue_index
gets unset or more accurately set to 0 as a default in xdp_rxq_info. This is my
current understanding.I still have to know how I can propogate that HW hint from
the NICs to the function where I need it.

This explains what this series does, the desired end state of
information passing, but not why is does it - how that information is
going to be consumed? To what end?

In my vision,The queue index propagated correctly through cpumap can help xdp
programs use it for things such as per queue load balancing,Adaptive RSS tuning
and even maybe for DDoS mitigation where they can drop traffic per queue.I mean
if these aren't correct intents or if they don't justify the added code, I can
abort working on it. Even if they weren't I need more guidance on how I can have
that metadata from HW hints...

Both filtering or load balancing you'd want to do early on - in the XDP
program invoked on receive from NIC, which as Stanislav pointed out
already has access to the RX queue index in its context. Not on the
remote CPU after spending cycles on a redirect.

And even if you wanted to pass that information to the remote XDP
program, to do something with it, you can already store it in custom XDP
metadata [1].

So while perhaps there is something that you can't do today but would be
useful, I don't know what it is. Hence my question about the use case.

[1] https://docs.ebpf.io/linux/helper-function/bpf_xdp_adjust_meta/

Very clear,
I will abort working on this since it can be passed as a custom XDP 
metadata [1] until further valid use cases or when it proves to be more 
useful.
Thank you for your review and time.
Best Regards,
Mehdi

[1] https://docs.ebpf.io/linux/helper-function/bpf_xdp_adjust_meta/