On Wed, Nov 13, 2019 at 4:48 PM Ilya Maximets <i.maxim...@ovn.org> wrote: > On 12.11.2019 21:13, David Marchand wrote: > > 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.
It works, but this is a hack. > > > 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. Not entering the debate on what is legacy. I agree that DPDK should provide a way to register threads. I don't remember discussion with OVS people when/if DPDK integration has been done. If it happened, pointers are welcome. Anyway, it seems worth looking at, but not necessarily easy. It would make dpdk a little more like a library. I will put this in my dpdk todolist (for the next release(s)). -- David Marchand _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev