> > On Fri, Jul 3, 2020 at 6:40 PM Ananyev, Konstantin > <konstantin.anan...@intel.com> wrote: > > what are the advantages of current approach (forbid MP support on the fly) > > over explicit start-up parameters (either --proc-type=single or > > --lcore-allow=...)? > > Why do you think it is a better one? > > I don't want to perpetuate the "please carefully set your command line" habit. > This feature is added through a C API, with documentation and flagged > as experimental, it should be enough. > > How about moving the mp disable in rte_thread_register() as a separate API? > Then a developer must call rte_mp_disable() before attempting > rte_thread_register(). > That would be equivalent to --proc-type=single.
It wouldn't be exactly the same thing, but yes, I agree user can call it as first thing after rte_eal_init() and it should help to prevent non-consistency in behaviour. I think it is a good compromise. > > Why not convert lcore-allow into an API? > This would force us to put something in the init so that external > users see how the application has been started and adjust the > secondary commandline. Not sure I understand you here... If we'll make lcore-allow dynamic it is basically the same as moving lcore_role[] (or some similar structure) into shared memory. I am ok with that, but I thought you stated that it would require quite a lot of work. > On the other hand, rte_mp_disable() is easy to do with my current v4 + > I am running out of time for rc1. Yes, as I said above such approach seems good enough to me (at least for now). Konstantin
