From: Paul Menzel <[email protected]> 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 <[email protected]> >> Reviewed-by: Aleksandr Loktionov <[email protected]> >> Signed-off-by: Alexander Lobakin <[email protected]> [...] >> 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
