When the trace buffers are saved to disk?

[Adel Belkhiri]

Thank you for your answer.

On Fri, Nov 29, 2024 at 4:23 PM Thomas Monjalon <thomas at monjalon.net> wrote:

> 29/11/2024 21:39, Adel Belkhiri:
> > Thank you for the clarification, Thomas. Indeed, the documentation for
> the
> > trace library is kind of limited. If you don't mind, I have another
> > question: Would it be useful to have an API to register a callback (to
> save
> > trace data) when the buffer is full?
>
> I suppose yes, the problem being which thread is running file writing.
>
> I leave it to the maintainers of the trace library.
>
>
> > On Fri, Nov 29, 2024 at 6:44 AM Thomas Monjalon <thomas at monjalon.net>
> wrote:
> > > 28/11/2024 20:17, Adel Belkhiri:
> > > > Hi all,
> > > >
> > > > Recently, while tracing applications from the apps and examples
> > > > directories, I became confused about when the trace buffer is
> written to
> > > > disk. Is the trace data saved only when rte_save_trace() is called,
> or
> > > does
> > >
> > > It is rte_trace_save()
> > >
> > > > it also automatically save when the buffer becomes full?
> > >
> > > No, DPDK is not doing such thing without user agreement.
> > >
> > > > From my understanding, rte_save_trace() is invoked when the
> application
> > > > executes rte_eal_cleanup(). Does this mean the target application
> needs
> > > to
> > > > explicitly support tracing by calling rte_save_trace()—perhaps at
> regular
> > > > intervals—to dump the trace buffer to disk? Otherwise, will we only
> get a
> > > > fragment of the trace saved during rte_eal_cleanup() execution?
> > >
> > > Yes you get it right.
> > >
> > > > Thank you for clarifying this point.
> > >
> > > Thanks for asking.
> > >
> > > If you think the doc below is not clear enough,
> > > do not hesitate to submit a patch to make the doc better:
> > >
> > >         https://doc.dpdk.org/guides/prog_guide/trace_lib.html
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mails.dpdk.org/archives/dev/attachments/20241129/9a5217ec/attachment-0001.htm>