On Fri, Sep 6, 2024 at 7:33 PM Ferruh Yigit <ferruh.yi...@amd.com> wrote: > > On 9/6/2024 2:11 PM, Jerin Jacob wrote: > > On Fri, Sep 6, 2024 at 3:04 PM Ferruh Yigit <ferruh.yi...@amd.com> wrote: > >> > >> On 9/5/2024 8:58 AM, David Marchand wrote: > >>> On Wed, Sep 4, 2024 at 8:10 PM Stephen Hemminger > >>> <step...@networkplumber.org> wrote: > >>>> > >>>> The API's in ethtool from before 23.11 should be marked stable. > >>> > >>> EAL* ? > >>> > >>>> Should probably include the trace api's but that is more complex change. > >>> > >>> On the trace API itself it should be ok. > >>> The problem is with the tracepoint variables themselves, and I don't > >>> think we should mark them stable. > >>> > >> > >> We cleaned tracepoint variables from ethdev map file, why they exist for > >> 'eal'? > >> > >> I can see .map file has bunch of "__rte_eal_trace_generic_*", I think > >> they exists to support 'rte_eal_trace_generic_*()' APIs which can be > >> called from other libraries. > >> > >> Do we really need them? > >> Why not whoever calls them directly call 'rte_trace_point_emit_*' instead? > >> As these rte_eal_trace_generic_*()' not used at all, I assume this is > >> what done already. > >> > >> @Jerin, > >> what do think to remove 'rte_eal_trace_generic_*()' APIs, so trace > >> always keeps local to library, and don't bloat the eal .map file? > > > > The purpose of exposing rte_eal_trace_generic_* is that, applications > > can add generic trace points > > in the application. > > > > Can't applications use 'rte_trace_point_emit_*()' directly, as libraries > does?
It is two different usages. 'rte_eal_trace_generic_ case is more like, application wants to simply emit int via generic trace API but not add any _new_ trace point.
