On Tue, Jul 28, 2020 at 9:30 AM Matan Azrad <ma...@mellanox.com> wrote: > > > > rte_lcore_to_cpu_id(-1) is supposed to return the current lcore id. > > > > As explained in the commitlog of 67ae5936c4fc36, for a non-EAL > > > > thread (which has no associated lcore by default) calling this > > > > function means lcore_config[-1].core_id. > > > > > > Deosn't lcore mean core? > > > > No. > > So, it may be that we have more than one lcore working on a specific cpu_id? > Can you extend here?
A control thread is a non-EAL thread. A non-EAL thread has no lcore associated (unless you call the newly added rte_thread_register API). Not sure why you need the physical core identifier in the driver. It is possible that non-EAL threads run on one physical core if you start your application with the right cpuset. But without checking, you can't make such an assumption. > > > > > > So, if the private thread run on a core that opened by EAL, Shouldn't > > > the API return the lcore of the private thread core? > > > > vhost-events is a control thread. > > Was it working just by chance and returning 0 before? > > Probably yes. (gdb) info symbol &lcore_config[-1].core_id vfio_cfgs + 444820 in section .bss of /home/dmarchan/git/pub/dpdk.org/build/app/../lib/librte_eal.so.20.0 Please, update the commitlog. Thanks. -- David Marchand
