> > 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
But secondary process can attach before lcore_register, so we'll have some sort of inconsistency in behaviour. If we really want to go ahead with such workaround - probably better to introduce explicit EAL flag ( --single-process or so). As Thomas and Bruce suggested, if I understood them properly.
