On Wed, Oct 2, 2024 at 9:09 PM Robin Jarry <rja...@redhat.com> wrote: > >> An alternative to this macro-fu, is to just define a single ethdev > >> telemetry function, and within that, take the lock and then dispatch to the > >> appropriate subfunction based upon the actual command coming in. The > >> dispatch may be slightly slower due to the additional text matching (only > >> from byte 8 onwards, so very short strings), but I think the code could be > >> a simpler in C rather than in macros, and the perf impact for telemetry is > >> likely to be negligible, compared to the overhead of the socket I/O etc. > > > > Hopefully, dispatching performance is not important here. > > I was going to suggest adding a rte_spinlock_t* parameter to a new > telemetry register function that would need to be held while the > callback is invoked. Or if we want to keep doors open to other kinds of > lock, a wrapper callback.
Well, as you had experimented this approach, we know this does not work: the ethdev lock is in dpdk shared memory which is not available yet at the time RTE_INIT() is called. A single callback is strange, I guess you mean pre/post callbacks then. -- David Marchand
