RE: tailqs issue

["Kompella V, Purnima" <Kompella.Purnima@commscope.com>]

OK.

Is it possible to declare an enum or a lookup table like "ops_name"(string) and "ops_index" (integer) pair in some common file.
Whether or not an OP is registered in the current build, the OP will always be associated with a fixed ops_index and this way ops_index really becomes shareable (like a database key) across different DPDK processes. 
Anyone contributing a new OP to DPDK must add it to the LOOKUP table. 

Both our Pri and Sec were built on the same code base, listed all the DPDK libs, just that the Makefiles had different order of listing the DPDK libs because Pri and Sec are built by
different teams in our org. 

OPs is not 'user-visible' when creating mempool, create-mempool DPDK API doesn't take OP name as input. 
This makes it very hard to troubleshoot, to find a starting point of where things may have gone wrong.

Just a thought.

Regards,
Purnima
 



-----Original Message-----
From: Stephen Hemminger <stephen@networkplumber.org> 
Sent: Wednesday, March 26, 2025 7:44 PM
To: Kompella V, Purnima <Kompella.Purnima@commscope.com>
Cc: Lombardo, Ed <Ed.Lombardo@netscout.com>; users@dpdk.org
Subject: Re: tailqs issue

CAUTION: This message originated from an External Source outside of CommScope.com. This may be a phishing email that can result in unauthorized access to CommScope. Please use caution when opening attachments, clicking links, scanning QR codes, or responding. You can report suspicious emails directly in Microsoft Outlook.




On Wed, 26 Mar 2025 10:27:40 +0000
"Kompella V, Purnima" <Kompella.Purnima@commscope.com> wrote:

> Hi Stephen
>
> Isn't it possible to gather all the MEMPOOL_REGISTER_OPS (xxx) calls 
> to a separate .c file in the dpdk source code Like say 
> drivers/mempool/common/rte_mempool_ops_reg.c containing below lines
>
> MEMPOOL_REGISTER_OPS(ops_stack);
> MEMPOOL_REGISTER_OPS(ops_lf_stack);
> MEMPOOL_REGISTER_OPS(ops_bucket);
> MEMPOOL_REGISTER_OPS(ops_bucket);
> MEMPOOL_REGISTER_OPS(octeontx_fpavf_ops);

That would be inflexible. Not every build needs all the ops.
If you want to fix, a better approach would be to harden the registration process.

Initializers and destructors are a problematic construct to debug.