Morten, On Thu, Dec 15, 2022 at 11:21 AM Morten Brørup <m...@smartsharesystems.com> wrote: > > > Shouldn't these callbacks be called from the EAL threads too, e.g. > > from eal_thread_loop()? > > > > > > I looks like they are only called from eal_lcore_non_eal_allocate(), > > which is only called from rte_thread_register(). > > > > These should be called for already present lcores on callback > > registration. > > See rte_lcore_callback_register(). > > That is completely useless! They need to be called from the thread itself, so > they have the correct environment, thread local storage, thread id, and > similar context.
If it is broken, please fix it or come with a better implementation. At the time, existing modules were storing their per lcore/thread private info using a local array and dereferencing it using rte_lcore_id() or a criteria of their liking. The callbacks have to be carefully written to explicitly initialise per lcore/thread private info. I thought it was enough, plus nobody objected. Now, some things to consider for this requirement you want to add. If we want an application to be able to register callbacks after rte_eal_init(), we need to wake/interrupt all EAL threads from what they are doing. Once EAL threads enter some job the application gave, they won't reread anything from EAL. Or we could require that callbacks are registered before rte_eal_init(), the init() callback could be called as the last step once all DPDK modules are initialised but before the application calls rte_eal_remote_launch(). But the problem of needing the break EAL threads from what they are doing is also present when we want to call the uninit() callback. And there, I have no good idea. -- David Marchand
