Re: [Intel-wired-lan] [PATCH iwl-next v3 1/5] libeth: pass Rx queue index to PP when creating a fill queue

[Alexander Lobakin]

From: Paul Menzel <pmenzel@xxxxxxxxxxxxx>
Date: Tue, 24 Feb 2026 19:53:11 +0100

> Dear Alexander,
> 
> 
> Thank you for your patch.
> 
> Am 24.02.26 um 18:46 schrieb Alexander Lobakin:
>> Since recently, page_pool_create() accepts optional stack index of
>> the Rx queue which the pool will be created for. It can then be
>> used on control path for stuff like memory providers.
>> Add the same field to libeth_fq and pass the index from all the
>> drivers using libeth for managing Rx to simplify implementing MP
>> support later.
>> idpf has one libeth_fq per buffer/fill queue and each Rx queue has
>> two fill queues, but since fill queues can never be shared, we can
>> store the corresponding Rx queue index there during the
>> initialization to pass it to libeth.
>>
>> Reviewed-by: Jacob Keller <jacob.e.keller@xxxxxxxxx>
>> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@xxxxxxxxx>
>> Signed-off-by: Alexander Lobakin <aleksander.lobakin@xxxxxxxxx>

[...]

>> diff --git a/include/net/libeth/rx.h b/include/net/libeth/rx.h
>> index 5d991404845e..3b3d7acd13c9 100644
>> --- a/include/net/libeth/rx.h
>> +++ b/include/net/libeth/rx.h
>> @@ -71,6 +71,7 @@ enum libeth_fqe_type {
>>    * @xdp: flag indicating whether XDP is enabled
>>    * @buf_len: HW-writeable length per each buffer
>>    * @nid: ID of the closest NUMA node with memory
>> + * @idx: stack index of the corresponding Rx queue
>>    */
>>   struct libeth_fq {
>>       struct_group_tagged(libeth_fq_fp, fp,
>> @@ -88,6 +89,7 @@ struct libeth_fq {
>>         u32            buf_len;
>>       int            nid;
>> +    u32            idx;
> 
> The type above and here is different (u16 vs u32), despite the
> description being the same. Could you enlighten me why, and maybe add it
> to the commit message?

The idpf queue index can never exceed U16_MAX and a u16 field stacks
nicely with other fields there. libeth is more generic and I in general
prefer to use 4+ byte long fields, hence u32.
I don't think it's anyhow important.

> 
> 
> Kind regards,
> 
> Paul
Thanks,
Olek