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