[dpdk-dev] [PATCH v5 00/33] DPDK Trace support

[David Marchand]

Thanks Jerin for this new version.

New round of comments.

- What do you think of splitting the API in two headers, thinking
about who will use them?
* rte_trace.h (rte_trace_ prefix for all functions/macros/types) for
users of the trace framework that want to
 * get the status of the whole trace subsystem,
 * enable/disable tracepoints by pattern/regexp,
 * dump the current events,
* rte_tracepoint.h (rte_tracepoint_ prefix for all
functions/macros/types) for developers that want to add tracepoints to
their code


- Having functions "is_disabled" has little value when a "is_enabled"
counterpart exists.


- What is the value of having a _public_ rte_trace_is_invalid() ?
A final user would need to lookup by name to get a trace descriptor
and we should hope that such a lookup returns a valid descriptor :-).
A developer would already have the descriptor hook point in his own
code: by construction, if the tracepoint is registered, then the
descriptor is valid, else, it is unknown.


- I did not get why we put the trace descriptors in a specific elf
section, can you explain the benefits?


- I can see no protection on the tracepoint list. Could we have issues
with control/application threads that dpdk does not control, dynamic
loading of libraries.. ?


- Following comment on v4 and the removal of the mode per tracepoint
api, don't we need to put the current select mode in each tracepoint
descriptor when registering a trace point ?


-- 
David Marchand