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

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

[Burakov, Anatoly]

Hi all,

While investigating this bug:

https://bugs.dpdk.org/show_bug.cgi?id=284

I came across a realization that, when primary process dies, very little 
actually works. There are some documented issues that are already 
present when secondary processes keep running, like memory map becoming 
static, and hotplug not working any more.

What is less known (and documented) is that VFIO also completely stops 
working when initializing processes, because some time since 18.xx 
releases, we've fixed a long standing VFIO-related bug that had to do 
with creating new containers every time a secondary is run - secondary 
processes will now reuse the primary process's container instead.

Meaning, for VFIO devices, secondary process *initialization* will fail 
after primary process has died, because there is no longer a process 
from which we can get the VFIO container from. Things will still sort-of 
work with igb_uio or in vfio-noiommu mode, but again - no memory map 
updates, no hotplug, potentially other things that i don't even know about.

Therefore, while ideally we would like people to have primary process 
always running, the least we can do to avoid documenting a complex 
matrix of "what is supported in which case" is to disallow secondary 
process initialization after primary process has died.

("disallow" as in "explicitly document it as unsupported", although we 
can also outright prevent it if we want - rte_eal_primary_proc_alive() 
will tell us that)

Thoughts?

-- 
Thanks,
Anatoly

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

[Bruce Richardson]

On Fri, Jul 26, 2019 at 10:05:02AM +0100, Burakov, Anatoly wrote:
> Hi all,
> 
> While investigating this bug:
> 
> https://bugs.dpdk.org/show_bug.cgi?id=284
> 
> I came across a realization that, when primary process dies, very little
> actually works. There are some documented issues that are already present
> when secondary processes keep running, like memory map becoming static, and
> hotplug not working any more.
> 
> What is less known (and documented) is that VFIO also completely stops
> working when initializing processes, because some time since 18.xx releases,
> we've fixed a long standing VFIO-related bug that had to do with creating
> new containers every time a secondary is run - secondary processes will now
> reuse the primary process's container instead.
> 
> Meaning, for VFIO devices, secondary process *initialization* will fail
> after primary process has died, because there is no longer a process from
> which we can get the VFIO container from. Things will still sort-of work
> with igb_uio or in vfio-noiommu mode, but again - no memory map updates, no
> hotplug, potentially other things that i don't even know about.
> 
> Therefore, while ideally we would like people to have primary process always
> running, the least we can do to avoid documenting a complex matrix of "what
> is supported in which case" is to disallow secondary process initialization
> after primary process has died.
> 
> ("disallow" as in "explicitly document it as unsupported", although we can
> also outright prevent it if we want - rte_eal_primary_proc_alive() will tell
> us that)
> 
Documenting this limitation seems a good thing to do. I'm not sure that
it's worthwhile trying to make the scenario (of running a secondary after a
primary has terminated) supported.

/Bruce

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

[Ananyev, Konstantin]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson
> Sent: Friday, July 26, 2019 10:40 AM
> To: Burakov, Anatoly <anatoly.burakov@intel.com>
> Cc: dev@dpdk.org; Thomas Monjalon <thomas@monjalon.net>
> Subject: Re: [dpdk-dev] Should we disallow running secondaries after primary has died?
> 
> On Fri, Jul 26, 2019 at 10:05:02AM +0100, Burakov, Anatoly wrote:
> > Hi all,
> >
> > While investigating this bug:
> >
> > https://bugs.dpdk.org/show_bug.cgi?id=284
> >
> > I came across a realization that, when primary process dies, very little
> > actually works. There are some documented issues that are already present
> > when secondary processes keep running, like memory map becoming static, and
> > hotplug not working any more.
> >
> > What is less known (and documented) is that VFIO also completely stops
> > working when initializing processes, because some time since 18.xx releases,
> > we've fixed a long standing VFIO-related bug that had to do with creating
> > new containers every time a secondary is run - secondary processes will now
> > reuse the primary process's container instead.
> >
> > Meaning, for VFIO devices, secondary process *initialization* will fail
> > after primary process has died, because there is no longer a process from
> > which we can get the VFIO container from. Things will still sort-of work
> > with igb_uio or in vfio-noiommu mode, but again - no memory map updates, no
> > hotplug, potentially other things that i don't even know about.
> >
> > Therefore, while ideally we would like people to have primary process always
> > running, the least we can do to avoid documenting a complex matrix of "what
> > is supported in which case" is to disallow secondary process initialization
> > after primary process has died.
> >
> > ("disallow" as in "explicitly document it as unsupported", although we can
> > also outright prevent it if we want - rte_eal_primary_proc_alive() will tell
> > us that)
> >
> Documenting this limitation seems a good thing to do. I'm not sure that
> it's worthwhile trying to make the scenario (of running a secondary after a
> primary has terminated) supported.
> 
> /Bruce

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.  

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

[Burakov, Anatoly]

On 26-Jul-19 10:50 AM, Ananyev, Konstantin wrote:
> 
> 
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson
>> Sent: Friday, July 26, 2019 10:40 AM
>> To: Burakov, Anatoly <anatoly.burakov@intel.com>
>> Cc: dev@dpdk.org; Thomas Monjalon <thomas@monjalon.net>
>> Subject: Re: [dpdk-dev] Should we disallow running secondaries after primary has died?
>>
>> On Fri, Jul 26, 2019 at 10:05:02AM +0100, Burakov, Anatoly wrote:
>>> Hi all,
>>>
>>> While investigating this bug:
>>>
>>> https://bugs.dpdk.org/show_bug.cgi?id=284
>>>
>>> I came across a realization that, when primary process dies, very little
>>> actually works. There are some documented issues that are already present
>>> when secondary processes keep running, like memory map becoming static, and
>>> hotplug not working any more.
>>>
>>> What is less known (and documented) is that VFIO also completely stops
>>> working when initializing processes, because some time since 18.xx releases,
>>> we've fixed a long standing VFIO-related bug that had to do with creating
>>> new containers every time a secondary is run - secondary processes will now
>>> reuse the primary process's container instead.
>>>
>>> Meaning, for VFIO devices, secondary process *initialization* will fail
>>> after primary process has died, because there is no longer a process from
>>> which we can get the VFIO container from. Things will still sort-of work
>>> with igb_uio or in vfio-noiommu mode, but again - no memory map updates, no
>>> hotplug, potentially other things that i don't even know about.
>>>
>>> Therefore, while ideally we would like people to have primary process always
>>> running, the least we can do to avoid documenting a complex matrix of "what
>>> is supported in which case" is to disallow secondary process initialization
>>> after primary process has died.
>>>
>>> ("disallow" as in "explicitly document it as unsupported", although we can
>>> also outright prevent it if we want - rte_eal_primary_proc_alive() will tell
>>> us that)
>>>
>> Documenting this limitation seems a good thing to do. I'm not sure that
>> it's worthwhile trying to make the scenario (of running a secondary after a
>> primary has terminated) supported.
>>
>> /Bruce
> 
> 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.

-- 
Thanks,
Anatoly

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

[Stephen Hemminger]

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.

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

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

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.

-- 
Thanks,
Anatoly

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

[Lipiec, Herakliusz]

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

> 
> 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.
> --
> Thanks,
> Anatoly

Re: [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@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.

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

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

[Lipiec, Herakliusz]

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

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

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

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


-- 
Thanks,
Anatoly

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

[Lipiec, Herakliusz]

> 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