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

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

> From: Burakov, Anatoly
> 
> On 26-Jul-19 5:44 PM, Lipiec, Herakliusz wrote:
> >
> >
> >> -----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).
> 
> To be completely clear, it's not like it's /dangerous/ to allow this sort of init. At
> least not currently. Things like ports will be missing from the process, but usually
> initialization is *attaching* to data, not creating new one. So, allowing such
> unsupported scenario is, strictly speaking, safe, at least for now.
> 
> I am not aware of any other "unsupported" operations that DPDK allows you to
> do, so that would be a first. There are debug modes for various libraries, but 1)
> they're compile time, 2) they're compile time for performance reasons, meaning
> we can't bake them in and enable them with a switch, and 3) they're not
> "unsupported", they're just not the default.

Well this could also be a compile time option right? 
Although eal switch sound like better solution tbh. What I meant by dangerous is 
that applications that allow for operations that shouldn’t be done, usually have a switch called
devmode/dangerous (like typical name for the "-i-know-what-im-doing" switch), not that this operation itself
is a dangerous one. 
> 
> >
> >>
> >> --
> >> Thanks,
> >> Anatoly
> 
> 
> --
> Thanks,
> Anatoly