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

[Jerin Jacob <jerinjacobk@gmail.com>]

On Fri, Oct 14, 2022 at 12:41 AM David Marchand
<david.marchand@redhat.com> wrote:
>
> On Thu, Oct 13, 2022 at 7:07 PM Harman Kalra <hkalra@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.

IMO, We can remove "already_done" logic, whenever, rte_trace_save()
called, it creates
the directory of that timestamp and copies the trace buffers. Since we
have "overwrite" and "discard"
modes, it is better to not add "already_done" dogic in rte_trace_save().


>
>
> --
> David Marchand
>