> > On Tue, Jun 30, 2020 at 8:57 PM Ananyev, Konstantin > <konstantin.anan...@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*).
Yes. > So is it not a problem of design/non-regression testing when > integrating the new API in the first place? Not sure I understand you here... If you saying that for SP benchmarking/testing current approach is sufficient, then - yes it is. Or are you saying it would be hard to create a test-case to reproduce such problematic scenario? > > > > 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
