> From: David Marchand [mailto:david.march...@redhat.com] > Sent: Friday, 16 December 2022 09.09 > > 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.
Apparently, you were not alone thinking it was enough. :-) > > > 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. Thank you for sharing your thoughts on this, David. Very valuable insights! I will try to determine the relevant scope and come up with a rough RFC, hoping to meet the December 25th proposal deadline for version 23.03. -Morten
