On 12.11.2019 21:13, David Marchand wrote: > On Tue, Nov 12, 2019 at 8:41 PM Ilya Maximets <[email protected]> wrote: >> >> On 12.11.2019 19:51, Stokes, Ian wrote: >>> >>> >>> On 11/12/2019 5:15 PM, David Marchand wrote: >>>> On Tue, Nov 12, 2019 at 6:07 PM Stokes, Ian <[email protected]> wrote: >>>>> On 11/11/2019 3:01 PM, Ilya Maximets wrote: >>>>>> DPDK commit 660098d61f57 ("pdump: use generic multi-process channel") >>>>>> switched pdump to use generic DPDK IPC instead of sockets. >>>>>> Old API was deprecated and removed. Updating OVS code accordingly. >>>>>> >>>>>> Signed-off-by: Ilya Maximets <[email protected]> >>>>> >>>>> Thanks for the patch Ilya. >>>>> >>>>> I see compilation passing now on dpdk-latest with this applied. >>>>> >>>>> https://travis-ci.org/istokes/ovs/builds/610915636 >>>>> >>>>> I still had issues with running PDUMP, but those issues are specific to >>>>> PDUMP setup in my environment. A separate issue we can discuss further >>>>> on the deprecation thread as it seems unrelated to this patch. >>>>> >>>>> @David, are you happy to ack the patch (I see some of the changes are >>>>> from your side). >>>> >>>> I did not work on the crash I saw, but it was most likely a problem on my >>>> side. >>>> This looks good to me. >>> >>> From a some further testing on my side I'm also seeing a crash, >>> specifically OVS crashes out once packets are received. PDUMP is still >>> running but complains of being unable to communicate with the primary >>> process and then exits. Is this similar to what you saw? >>> >>> @Ilya, by chance did you see anything like this? >> >> >> Honestly, I never tried to use pdump, and I don't really want to try >> preparing the setup for it (building ASLR disabled kernel and stuff). >> >> >>> I'll investigate further myself tomorrow. I was going to hold off on the >>> merge in the meantime. Thoughts? >> >> There are 2 options here: >> 1. Apply this patch and hope that DPDK will be fixed someday. >> + Optionally apply deprecation patch. > > This is pure speculation, but when I saw the crash before, I thought > that the problem was in the way ovs creates its thread without the > dpdk being aware of it.
At least, lcore_ids are set. > dpdk pdump component expects that it's running on a EAL thread, with a > known lcore, and *boom* when it dereferences some uninitialized > structures/resources. > > I did not really investigate, I just fear we have this class of > issues, since dpdk (and its sub components) is not instructed by ovs > how it placed its threads. > ovs has been doing this for some time, without people hitting bugs, so > I might just be paranoid. BTW, it seems for me that all this "EAL threads" concept is an "RTE" legacy. I understand that automatic support for dynamically created threads in the outer application sounds like a Sci-Fi fantasy, but as far as DPDK tries to be a library, I think, it should at least allow users to register their own threads. Large applications that wants to use DPDK, but also wants to be usable without it will likely not use EAL-threads because it's not flexible and not re-usable. Otherwise they will need to create layers of proxy libraries to abstract their thread management. Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
