[EXT] [PATCH v3 5/9] trace: fix dynamically enabling trace points

David Marchand david.marchand at redhat.com
Thu Oct 13 21:10:51 CEST 2022


On Thu, Oct 13, 2022 at 7:07 PM Harman Kalra <hkalra at marvell.com> wrote:
> >
> > With the whole traces fixes series applied first, then the new "trace:
> > take live traces via telemetry" patch applied, I can't reproduce your issue.
> >
> >
>
> Yes, you replicated the same scenario what I tried.
> Sorry, I realized that actually it's not an issue, traces generated after /trace/save are getting
> appended but in the same file (timestamped on /trace/save) on rte_eal_cleanup().
>
> I assumed that trace dir generated with a timestamp will include all the trace points emitted
> before that timestamp. But in the above scenario same  trace dir includes trace points emitted
> after this timestamp. I think this is bit confusing. Shall we add a logic where if already_done is
> set, rename the original trace dir to latest timestamp?

Afaiu, the behavior before this series was the same.
An application calling rte_trace_save() would always save to a single directory.
One thing that changed though is that the directory is timestamped
with the time of the first call to rte_trace_save.
Before the seriesn the timestamp was based on the time when the trace
subsystem was initialised.


We can go with what you describe (which makes sense to me).
But I'd like to get a ack from traces maintainers before looking into it.


-- 
David Marchand



More information about the stable mailing list