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

[Burakov, Anatoly]

On 26-Jul-19 4:56 PM, Lipiec, Herakliusz wrote:
> 
> 
>> From: dev [mailto:dev-bounces at 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 at 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.

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!

-- 
Thanks,
Anatoly