[dpdk-dev] [PATCH v3 6/9] eal: register non-EAL threads as lcores

David Marchand david.marchand at redhat.com
Wed Jul 1 09:48:50 CEST 2020


On Tue, Jun 30, 2020 at 8:57 PM Ananyev, Konstantin
<konstantin.ananyev at intel.com> wrote:
> Imagine the situation - there is a primary proc (supposed to run forever)
> that does  rte_thread_register/rte_thread_unregister during its lifetime.
> Plus from time to time user runs some secondary process to collect stats/debug
> the primary one (proc-info or so).
> Now behaviour of such system will be non-deterministic:
> In some runs primary proc will do rte_thread_register() first,
> and then secondary proc will be never able to attach.
> In other cases - secondary will win the race, and then for primary
> eal_lcore_non_eal_allocate() will always fail.
> Which means different behaviour between runs, varying performance, etc.

If the final users finally hit the situation you describe, it means
that the multiprocess had been in use so far and was known to be in
use (*hopefully*).
So is it not a problem of design/non-regression testing when
integrating the new API in the first place?


> > If we don't add any new option now, and restrict MP handling
> > to error messages, it would not prevent from extending
> > in future, right?
>
> It shouldn't I think.
> Though what is the urgency to push this feature without having an
> agreement first?

I waited to see others' opinions (and pinged some OVS-DPDK people).
I'd like an agreement too.


-- 
David Marchand



More information about the dev mailing list