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. > >
