30/06/2020 14:44, Olivier Matz: > On Tue, Jun 30, 2020 at 12:07:32PM +0000, Ananyev, Konstantin wrote: > > I think it is better than nothing, but probably not the best one. > > Apart from possible non-consistent behaviour, it is quite restrictive: > > dynamic lcore_id wouldn't be available on any DPDK MP deployment. > > Which is a pity - I think it is a cool and useful feature. > > > > What do you guys think about different approach: > > introduce new optional EAL parameter to restrict lcore_id > > values available for the process. > > > > #let say to start primary proc that can use lcore_id=[0-99] only: > > dpdk_primary --lcore-allow=0-99 ... --file-prefix=xz1 > > > > #to start secondary one for it with allowed lcore_id=[100-109]: > > dpdk_secondary --lcore-allow=100-109 ... --file-prefix=xz1 > > --proc-type=secondary > > > > It is still a workaround, but that way we don't need to > > add any new limitations for dynamic lcores and secondary process usage. > > Now it is up to user to decide would multiple-process use the same shared > > data > > and if so - split lcore_id space properly among them > > (same as he has to do now with static lcores). > > A variant (more simple) of your approach could be to add > "--proc-type=standalone" to explicitly disable MP and enable dynamic thread > registration.
I don't adding a restriction from user input is adding a feature. Konstantin wants to support multi-process with non-EAL threads, which is the opposite of your proposal, Olivier :-)
