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 <step...@networkplumber.org> 
Sent: Wednesday, March 26, 2025 7:44 PM
To: Kompella V, Purnima <kompella.purn...@commscope.com>
Cc: Lombardo, Ed <ed.lomba...@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.purn...@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.

Reply via email to