Re: [dpdk-dev] Should we disallow running secondaries after primary has died?

["Lipiec, Herakliusz" <herakliusz.lipiec@intel.com>]

> From: dev [mailto:dev-bounces@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.burakov@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