Hi Olivier,
On 5/13/19 3:14 PM, Olivier Matz wrote:
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.
Suggested solution looks good to me.
Thanks,
Andrew.
