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

David Marchand david.marchand at redhat.com
Mon Jun 15 09:11:45 CEST 2020


On Wed, Jun 10, 2020 at 5:33 PM Jerin Jacob <jerinjacobk at gmail.com> wrote:
>
> 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?

- All caches are initialised for all possible lcores for each mempool.
https://git.dpdk.org/dpdk/tree/lib/librte_mempool/rte_mempool.c#n965
So any order is fine wrt the local mempool cache.

- If the mempool drivers want to initialise per lcore data on demand
[1], the driver have to register a lcore notifier per mempool.
1: https://git.dpdk.org/dpdk/tree/drivers/mempool/bucket/rte_mempool_bucket.c#n437

But this current series implementation does not handle registering in any order.
I will fix this in v2 (and rework the locking which is quite ugly)
hopefully this week.


-- 
David Marchand



More information about the dev mailing list