> > From: Konstantin Ananyev [mailto:konstantin.anan...@huawei.com] > > Sent: Tuesday, 17 September 2024 01.20 > > > > > > > +/** > > > > > + * Get pointer to lcore variable instance of the current thread. > > > > > + * > > > > > + * May only be used by EAL threads and registered non-EAL threads. > > > > > + */ > > > > > +#define RTE_LCORE_VAR_VALUE(handle) \ > > > > > + RTE_LCORE_VAR_LCORE_VALUE(rte_lcore_id(), handle) > > > > > > > > Would it make sense to check that rte_lcore_id() != LCORE_ID_ANY? > > > > After all if people do not want this extra check, they can probably use > > > > RTE_LCORE_VAR_LCORE_VALUE(rte_lcore_id(), handle) > > > > explicitly. > > > > > > Not generally. I prefer keeping it brief. > > > We could add a _SAFE variant with this extra check, like LIST_FOREACH has > > LIST_FOREACH_SAFE (although for a different purpose). > > > > > > Come to think of it: In the name of brevity, consider renaming > > RTE_LCORE_VAR_VALUE to RTE_LCORE_VAR. (And > > > RTE_LCORE_VAR_FOREACH_VALUE to RTE_LCORE_VAR_FOREACH.) We want to see > > > these > > everywhere in the code. > > > > Well, it is not about brevity... > > I just feel uncomfortable that our own public macro doesn't check value > > returned by rte_lcore_id() and introduce a possible out-of-bound memory > > access. > > For performance reasons, we generally don't check parameter validity in fast > path functions/macros; lots of code in DPDK uses ptr- > >array[rte_lcore_id()] without checking rte_lcore_id() validity.
Yes there are plenty of such places inside DPDK... Ok, I'll leave it for the author to decide, after all there is a clear comment in front of it forbidding to use that macro for non-EAL threads. Hope users will read it before using ;) > We shouldn't do it here either. > > There's a secondary benefit: > RTE_LCORE_VAR_VALUE() returns a pointer, so this macro can always be used. > Especially, the pointer can be initialized with other variables at the start > of a function: > struct mystruct * const state = RTE_LCORE_VAR_VALUE(state_handle); > The out-of-bound memory access will occur if dereferencing the pointer. >
