Re: [PATCH RFC 0/4] Add XDP RX queue index metadata via kfuncs

Mehdi Ben Hadj Khelifa
2025-09-25T11:03:18Z

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:
>> On 9/25/25 11:18 AM, Jakub Sitnicki wrote:
>>> On Thu, Sep 25, 2025 at 11:54 AM +01, Mehdi Ben Hadj Khelifa wrote:
>>>> On 9/25/25 10:43 AM, Jakub Sitnicki wrote:
>>>>> On Tue, Sep 23, 2025 at 10:00 PM +01, Mehdi Ben Hadj Khelifa wrote:
>>>>>> 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/