> 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-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. > >> > >> 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
