03/11/2022 10:02, Morten Brørup: > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of David Marchand > > Sent: Monday, 6 July 2020 22.53 > > > > DPDK allows calling some part of its API from a non-EAL thread but this > > has some limitations. > > OVS (and other applications) has its own thread management but still > > want to avoid such limitations by hacking RTE_PER_LCORE(_lcore_id) and > > faking EAL threads potentially unknown of some DPDK component. > > > > Introduce a new API to register non-EAL thread and associate them to a > > free lcore with a new NON_EAL role. > > This role denotes lcores that do not run DPDK mainloop and as such > > prevents use of rte_eal_wait_lcore() and consorts. > > > > Multiprocess is not supported as the need for cohabitation with this > > new > > feature is unclear at the moment. > > > > Signed-off-by: David Marchand <david.march...@redhat.com> > > Acked-by: Andrew Rybchenko <arybche...@solarflare.com> > > Acked-by: Thomas Monjalon <tho...@monjalon.net> > > --- > > Following up on a two+ years old patch series, triggered by the discussion > [1] about statistics counters in the mempool library... > > The rte_lcore_role_t enum values are missing the RTE_ prefix, and the > meanings of the four values should be documented with comments in the source > code. > > Also, the documentation [2] could benefit from some elaboration about the > lcore roles. I had to read the source code in depth to understand that each > "registered non-EAL thread" has a unique lcore_id, which is not used by any > other EAL or non-EAL thread.
You probably have the best point of view to improve the documentation. Feel free to work on a patch. > [1]: > http://inbox.dpdk.org/dev/98cbd80474fa8b44bf855df32c47dc35d87...@smartserver.smartshare.dk/T/#u > [2]: > http://doc.dpdk.org/guides/prog_guide/env_abstraction_layer.html#multiple-pthread
