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

[Jerin Jacob]

On Wed, Jun 10, 2020 at 8:48 PM David Marchand
<david.marchand at redhat.com> wrote:
>
> 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.

Was it the case when lcore registered and then mempool created? What
about other case, mempool created and then lcore registered?


> We could imagine flushing such caches on unregistering.
>
> And we can fix other mempool drivers like the bucket driver.
>
> --
> David Marchand
>