Hi Gage, On Thu, May 09, 2019 at 10:19:55PM +0000, Eads, Gage wrote: > Hi all, > > I ran into a problem with a multi-process application, in which two processes > assigned the same mempool handler ops index to *different* handlers. This > happened because the two processes supplied the -d EAL arguments in different > order, e.g.: > > sudo ./appA -dlibrte_mempool_bucket.so -dlibrte_mempool_ring.so --proc-type > primary & > sudo ./appB -dlibrte_mempool_ring.so -dlibrte_mempool_bucket.so --proc-type > secondary & > > The dynamic load order matters because the ops indexes are assigned in the > order the library ctors are run. This can result in the different processes > trying to use different handlers for the same mempool. > > I'm not aware of any requirement that the EAL argument order should match > across processes, so I don't think this is a user error. This could also > happen in static libraries if they linked the libraries in a different order > - but that shouldn't occur if both applications are following the rules for > building an external application > (https://doc.dpdk.org/guides/prog_guide/dev_kit_build_system.html#building-external-applications). > > If you agree that this is an issue, I see a couple possible resolutions: > > > 1. Add a note/warning to the mempool handlers section of the user guide > (https://doc.dpdk.org/guides/prog_guide/mempool_lib.html#mempool-handlers) > > 2. Modify rte_mempool_register_ops() so that built-in handlers (ring, > stack, etc.) have fixed IDs. E.g. ring is always 0, stack is always 1, etc. > These handlers could be identified by their name string. User-registered > mempools would still be susceptible to this problem, though. > > Thoughts? Alternatives?
What about this: - add a new table in a named memory zone that stores the association between mempool_ops id and name (but not the ops pointers) of the primary process. - change rte_mempool_register_ops() to have a specific behavior in case of a secondary process: lookup in that table to get the id associated to the name (fail if not found). On the other hand, using secondary processes always looked a bit dangerous to me (for several reasons), so adding a note in the programmer's guide (your proposal 1) is also fine to me. Thanks, Olivier
