Created attachment 219 [details] GDB print value corresponding to the table（rte_mempool_ops_table）（myapp and dpdk-pdump） The `rte_mempool_ops_table` is process unsafe! When a process is started, the table (rte_mempool_ops_table) will be initialized with a macro (rte_mempool.h:MEMPOOL_REGISTER_OPS). However, different process initialization will cause inconsistent index values (ops_index) (such as myapp and dpdk pdump). After the initialization memory pool is created in the dpdk pdump process, mp->ops_index = 0, mp->ops_index=2 in myapp。 Different processes using the shared memory pool will be coredump
Hi, IMO, the drivers should be loaded in the same order in primary and secondary processes, except if they are built in different environments. Can you explain precisely how to reproduce the issue, starting from the compilation step? This issue has been mentioned some time ago on the mailing list: http://inbox.dpdk.org/dev/1586787714-13890-1-git-send-email-xiangxia.m.yue@gmail.com/#r The problem to implement the feature is that mempool driver registration is done very early (in constructors), where shared memory functions are not available. As far as I know, there is no place where the mempool can hook itself to have a callback invoked when the eal init is done. I tried to rework Xianxia's patch few monthes ago so that it does not require a specific init layer, hijacking the vdev registration instead, but it is not convincing. See attached patch for reference. I also had a look to multiprocess communication channels, but I didn't find anything useful to solve this issue. I think we would need a callback when the secondary process is connected to the primary. If you can demonstrate a usecase, I think you could try resurrect the discussion about introducing a new rte_init with priorities on the mailing list. The attached patch can probably be reworked to take advantage of it.
Created attachment 221 [details] DRAFT to fix mempool drivers in secondary
1. I compiled the dpdk as static library and pdump at the same time 2. my app link the libdpdk.a Then the above problem arises. Here's my solution, see github : https://github.com/DPDK/dpdk/pull/51 At each registration, sort by rte_mempool_ops::name.
(In reply to Olivier Matz from comment #2) > Created attachment 221 [details] > DRAFT to fix mempool drivers in secondary Maybe it could be simpler? see my solution: https://github.com/DPDK/dpdk/pull/51 At each registration, sort by rte_mempool_ops::name.