+CC Mattias, I forgot to put you on this discussion > From: David Marchand [mailto:david.march...@redhat.com] > Sent: Thursday, 15 December 2022 10.09 llbacks > > On Thu, Dec 15, 2022 at 10:05 AM Morten Brørup > <m...@smartsharesystems.com> wrote: > > > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of David Marchand > > > Sent: Monday, 6 July 2020 22.53 > > > > > > DPDK components and applications can have their say when a new > lcore is > > > initialized. For this, they can register a callback for > initializing > > > and > > > releasing their private data. > > > > > > Signed-off-by: David Marchand <david.march...@redhat.com> > > > --- > > > > David, > > > > 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. Here is an example why: http://inbox.dpdk.org/dev/dm4pr18mb4368eee47c1fe95dd73ce3fcd2...@dm4pr18mb4368.namprd18.prod.outlook.com/T/#m3f6bb60ce19bdbba594e1212e8f17358ac1f9d3e When I saw them called from rte_lcore_callback_register(), I thought it was for some sort of pre-initialization or validation purposes.
