> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Burakov, Anatoly > On 26-Jul-19 4:01 PM, Stephen Hemminger wrote: > > On Fri, 26 Jul 2019 10:53:58 +0100 > > "Burakov, Anatoly" <anatoly.bura...@intel.com> wrote: > > > >>> > >>> NP to disallow it. > >>> In fact, I think it would be easier for everyone just to drop > >>> current DPDK MP model, and keep just standalone DPDK instances. > >> > >> That's the dream, but i don't think it'll ever come to fruition, at > >> least not without a huge push from the community. > > > > There are several net appliances that require primary/secondary model. > > I think initially during DPDK development it was sold as a feature to > > the Network vendors. > > > > It might be possible to clamp down on what API's are supported by > > secondary process. For example, disallowing any control operations > > start/stop > etc. > > > > We're getting slightly off topic here. > > The original question was about whether we want to support a use case where a > secondary can initialize after primary process has died, and if we don't, > whether > we want to 1) outright deny initialization, or 2) allow it, but document as > unsupported and discourage it. Allowing something that is unsupported sounds like asking for trouble.
> > The only use case i can think of that would require it is proc-info app. > Dumping stuff from a dead process can be useful for debugging, so perhaps we > can agree to put a warning at EAL startup, saying that this is not supported, > but > still allow processes to initialize. > If this is supposed to be useful for debugging then maybe allow only when some kind of flag is passed to eal? This would also prevent from initializing the process incidentally. > -- > Thanks, > Anatoly
