[dpdk-dev] [PATCH v6 07/10] eal: add lcore init callbacks

[Morten Brørup]

> From: David Marchand [mailto:david.marchand at redhat.com]
> Sent: Friday, 16 December 2022 09.09
> 
> Morten,
> 
> On Thu, Dec 15, 2022 at 11:21 AM Morten Brørup
> <mb at 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