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

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

> -----Original Message-----
> From: Burakov, Anatoly
> 
> On 26-Jul-19 4:56 PM, Lipiec, Herakliusz wrote:
> >
> >
> >> 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.
> 
> We wouldn't be "allowing" it as much as we'd just be disclaiming any
> responsibility for when things go wrong, *if* someone tries that. I suppose the
> concern is that someone would try that /accidentally/, and possibly screw up
> other secondary processes that may still be running.
> 
> >
> >>
> >> 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.
> 
> We have too many EAL flags as it is! I suppose this could be done -
> proc-info already hardcodes the "--proc-type" flag so that it only ever
> runs as a secondary, we could add another one there. So, technically,
> this is doable.
Well it’s a bad idea to allow this without any "yes I know what I'm doing" 

> 
> I'm just not sure of the prospect of adding a yet another EAL flag to
> serve a purpose of enabling one specific application to run. That said,
> an "--i-know-what-i-am-doing" flag certainly sounds like a fun idea!
Well are there any other "unsupported" operations in dpdk ? 
Maybe one "--i-(don’t)-know-what-i-am-doing" aka debug (devmode, dangerous or whatever) flag 
is a good option to enable/disable these kind of behaviours and cover them all, 
this would definitely help preventing someone from doing this accidentally, or unknowingly (for example from within a script).

> 
> --
> Thanks,
> Anatoly