Re: [PATCH 0/3] eal: mark API's as stable

[Jerin Jacob <jerinjacobk@gmail.com>]

On Fri, Sep 6, 2024 at 7:33 PM Ferruh Yigit <ferruh.yigit@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.yigit@amd.com> wrote:
> >>
> >> On 9/5/2024 8:58 AM, David Marchand wrote:
> >>> On Wed, Sep 4, 2024 at 8:10 PM Stephen Hemminger
> >>> <stephen@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.