On Wed, Jun 10, 2020 at 8:48 PM David Marchand <david.march...@redhat.com> wrote: > > On Wed, Jun 10, 2020 at 5:09 PM Jerin Jacob <jerinjac...@gmail.com> wrote: > > > > On Wed, Jun 10, 2020 at 8:15 PM David Marchand > > <david.march...@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 >
