On Wed, Jun 10, 2020 at 08:39:30PM +0530, Jerin Jacob 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. >
+1 for this, this is something that I think has been needed for a long time. Thanks! > Is mempool's lcore local cache working for external cores with this scheme? > > > > > > For the interested parties, I have a patch [1] against dpdk-latest OVS > > branch that makes use of this series. > > > > 1: https://github.com/david-marchand/ovs/commit/dpdk-latest-external-lcores > > Usage is clear from the example code, > Looking forward to having documentation and UT for the new API > in the next version. > Yes, I think we need a doc update explaining usage. The EAL chapter of the programmers guide needs an update [1], and I think a description in the howto would be good also [2]. [1] https://doc.dpdk.org/guides-20.05/prog_guide/env_abstraction_layer.html [2] https://doc.dpdk.org/guides-20.05/howto/index.html Regards, /Bruce
