[ovs-dev] [PATCH v3] dpdk: Migrate to the new pdump API.

[David Marchand]

On Wed, Nov 13, 2019 at 4:48 PM Ilya Maximets <i.maximets at 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