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