Hi Tonghao, On Mon, Mar 16, 2020 at 03:43:40PM +0800, Tonghao Zhang wrote: > On Mon, Mar 9, 2020 at 9:15 PM David Marchand <[email protected]> > wrote: > > > > On Mon, Mar 9, 2020 at 9:56 AM Tonghao Zhang <[email protected]> > > wrote: > > > On Mon, Mar 9, 2020 at 4:27 PM Olivier Matz <[email protected]> > > > wrote: > > > > The fact that the ops index changes during mempool driver lifetime is > > > > indeed frightening, especially knowning that this is a dynamic > > > > registration that could happen at any moment in the life of the > > > > application. Also, breaking the ABI is not desirable. > > > That solution is better. > > > > > > > Let me try to propose something else to solve your issue: > > > > > > > > 1/ At init, the primary process allocates a struct in shared memory > > > > (named memzone): > > > > > > > > struct rte_mempool_shared_ops { > > > > size_t num_mempool_ops; > > > > struct { > > > > char name[RTE_MEMPOOL_OPS_NAMESIZE]; > > > > } mempool_ops[RTE_MEMPOOL_MAX_OPS_IDX]; > > > > char *mempool_ops_name[RTE_MEMPOOL_MAX_OPS_IDX]; > > > > rte_spinlock_t mempool; > > > > } > > > > > > > > 2/ When we register a mempool ops, we first get a name and id from the > > > > shared struct: with the lock held, lookup for the registered name and > > > > return its index, else get the last id and copy the name in the > > > > struct. > > > > > > > > 3/ Then do as before (in the per-process global table), except that we > > > > reuse the registered id. > > > > > > > > We can remove the num_ops field from rte_mempool_ops_table. > > > > > > > > Thoughts? > > > > It seems better, just adding Anatoly and Bruce who know more about > > multiprocess. > > > > Tonghao, could you add a unit test to exhibit the issue as part of this > > work? > > > > Thanks. > Hi Olivier > any progress？will apply this patch or wait your patch?
Sorry if it wasn't clear, but my proposition was just an idea, I have no time yet to work on it. Feel free to implement it by yourself, and I'll help to review the patches. Thanks, Olivier
