On Thu, Oct 6, 2022 at 9:50 AM Andrew Rybchenko
<andrew.rybche...@oktetlabs.ru> wrote:
> >>>>> diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map index
> >>>>> 3def7bfd24..e3d603cc9a 100644
> >>>>> --- a/lib/ethdev/version.map
> >>>>> +++ b/lib/ethdev/version.map
> >>>>> @@ -288,6 +288,150 @@ EXPERIMENTAL {
> >>>>>
> >>>>> # added in 22.11
> >>>>> rte_flow_async_action_handle_query;
> >>>>> + __rte_eth_trace_add_first_rx_callback;
> >>>>
> >>>> Why is it in EXPERIMENTAL section, but not INTERNAL?
> >>> [Ankur] Because the functions for which trace is added are not internal
> >> functions.
> >>
> >> Sorry, but I don't understand. I agree that tracing of public inline
> >> functions
> >> must be part of ABI, but why everything else should be a part of ABI?
> > [Ankur] I see that there are some already existing trace functions added in
> > EXPERIMENTAL in version.map like __rte_ethdev_trace_configure,
> > __rte_ethdev_trace_rxq_setup. So not sure will it be internal or
> > experimental.
> >
> > But you are right the trace function will not be called as a public api.
> > Should I make the newly added trace as internal then?
>
> @David, do I understand correctly that trace points in
> EXPERIMENTAL is a mistake in majority of cases?
The trace point global variables (__rte_trace_foo) are only exposed
for inline helpers that might call their associated trace point helper
(rte_trace_foo()).
An application is not supposed to directly manipulate them.
Any tp manipulation should be through the rte_trace_point_* API.
Jerin, do you see any other uses for them?
If not, I agree we can mark all those INTERNAL.
I can send a cleanup post rc1.
--
David Marchand
