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

["Burakov, Anatoly" <anatoly.burakov@intel.com>]

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.

> 
>>
>> --
>> Thanks,
>> Anatoly


-- 
Thanks,
Anatoly