On Wed, Jun 24, 2020 at 12:40 PM Ananyev, Konstantin <konstantin.anan...@intel.com> wrote: > > Supporting lcore allocation in MP requires exchanges between > > primary/secondary processes like what we have for memory allocations. > > It will be quite a beast to get to work fine, while not even knowing > > if people actually want to use both. > > I don't think we need to re-implement RPC as we did for memory subsystem. > One relatively simple approach - move lcore_role[] and related lock into > shared memory (separate memzone or so). > I think it should help a lot and will solve majority of the problems. > One limitation - init/fini callbacks can be static only. > As the drawback, it will introduce change in current behaviour: > secondary process with lcore-mask that intersects with master lcore-mask > will fail to start. > Second approach - make lcore_id local process entity: > prohibit indexing by lcore_id in shared data structures. > Let say for mempool - make cache local (per process). > While that approach is probably more elegant and consistent, > it would require more work and will cause ABI (maybe API also) breakage.
In all scenarii, this is quite some work. > > > For v4, I added a check to exclude MP and the new API. > > Do you mean - make this new dynamic-lcore API return an error if callied > from secondary process? > Yes, and prohibiting from attaching a secondary process if dynamic lcore API has been used in primary. I intend to squash in patch 6: https://github.com/david-marchand/dpdk/commit/e5861ee734bfe2e4dc23d9b919b0db2a32a58aee -- David Marchand
