On Mon, Jul 6, 2020 at 10:53 PM David Marchand <[email protected]> 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 threads > to such lcores. > non-EAL threads won't run the DPDK eal mainloop. > 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 introducing init/uninit > callacks invoked when hotplugging of such lcore. > > There is still some work/discussion: > - refuse new lcore role in incompatible EAL threads API (or document it > only as those API were already incompatible?), > - think about deprecation notices for existing RTE_FOREACH_LCORE macros > and consorts, it is probably worth discussing on how to iterate over > lcores, > > For the interested parties, I have a patch [1] against dpdk-latest OVS > branch that makes use of this series (this patch probably won't work with > v5, it will be rebased once dpdk side is ready). > > 1: > https://patchwork.ozlabs.org/project/openvswitch/patch/[email protected]/
Series applied with last comments from Konstantin. -- David Marchand
