[dpdk-dev] [PATCH 0/7] Register external threads as lcore

David Marchand david.marchand at redhat.com
Wed Jun 10 17:18:25 CEST 2020


On Wed, Jun 10, 2020 at 5:09 PM Jerin Jacob <jerinjacobk at gmail.com> wrote:
>
> On Wed, Jun 10, 2020 at 8:15 PM David Marchand
> <david.marchand at redhat.com> wrote:
> >
> > OVS and some other applications have been hacking into DPDK internals to
> > fake EAL threads and avoid performance penalty of only having non-EAL
> > threads.
> >
> > This series proposes to add a new type of lcores and maps those external
> > threads to such lcores.
> > Those threads won't run the DPDK eal mainloop and as a consequence part of
> > the EAL threads API cannot work.
> >
> > Having new lcores appearing during the process lifetime is not expected
> > by some DPDK components. This is addressed by notifying of such lcore
> > hotplug.
> >
> > This patchset has still some more work (like refusing new lcore type in
> > incompatible EAL threads API, updating the documentation and adding unit
> > tests) but I am sending it anyway as I would like to get this in for
> > 20.08.
>
> Cool feature.
>
> Is mempool's lcore local cache working for external cores with this scheme?

Yes, as it is stateless, all we need is a unique lcore_id in [0,
RTE_MAX_LCORE-1] range.
We could imagine flushing such caches on unregistering.

And we can fix other mempool drivers like the bucket driver.

-- 
David Marchand



More information about the dev mailing list