Hi, I am trying to test the newly added DPDK Trace Library in DPDK 20.08. I created a DPDK trace point as follows: Defined the trace point in the header file: ################################################# #include <rte_trace_point.h> RTE_TRACE_POINT( app_dpdk_tx_tp, RTE_TRACE_POINT_ARGS(const char *str), rte_trace_point_emit_string(str); ) ################################################## Registered the trace point as follows: ###################################################### #include <rte_trace_point_register.h> #include "dpdk_UDP_trace_Tx.h" RTE_TRACE_POINT_REGISTER(app_dpdk_tx_tp, app.dpdk.tx.tp) ###################################################### In my application, I try to emit simple string using the above trace-point: *app_dpdk_tx_tp("Test trace string");* I run the program as follows: $sudo ./build/app/udpTx -n 4 -l 2 --trace-dir=/home/upandey/dpdk-traces --trace=.* The resulting trace file when analyzed using babeltrace does contain traces from DPDK libraries but it does not have the traces which I have added to the application. I have tried running with the "discard" option as well, but the result is the same. I have the following questions: 1. Am I missing something in declaring and registering the trace-point? 2. Do I have to enable some config parameters in DPDK to be able to get the user-defined traces? Thanks and regards, Utkarsh Pandey
[-- Attachment #1: Type: text/plain, Size: 276 bytes --] Seeing as this has no reply and I ran into the problem too, I am posting a solution here. Because the trace API was (is?) experimental, some of the calls are translated to RTE_SET_USED(). You need to define ALLOW_EXPERIMENTAL_API in the caller's source file at the very top. [-- Attachment #2: Type: text/html, Size: 326 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1721 bytes --] Hi, I am trying to test the usage of the DPDK trace library. I have run into the same issue as recounted here - https://mails.dpdk.org/archives/users/2020-December/005266.html <https://mails.dpdk.org/archives/users/2020-December/005266.html> - where I am able to build and run my DPDK application where I have created and registered my custom trace point (verified via rte_trace_dump(stdout) which says my traces are 'enabled' - i see the right trace buffer size, trace file destination etc). The trace point creation and registration are identical to what is mentioned in the program guide using RTE_TRACE_POINT in a header file and registering it in my dpdk application via RTE_TRACE_POINT_REGISTER macro. What I notice are as follows: 1. The program builds and runs as intended. 2. The trace files are generated in the correct destination directory. 3. On using trace=.* ----> I see a huge list of traces on viewing the trace file with babeltrace - but do not see my custom trace point. I also do not see any trace output from my dpdk application if I reuse DPDK library traces ( eg: rte_eal_trace_thread_lcore_ready ) instead of defining my own custom traces. 4. On using trace=<regex for traces used in my application> i do not see any trace output just used inside my application. I think the above observations suggest that the issue might be in configuring my DPDK application to recognize and create trace output properly. However the rte_trace_dump output suggests that trace is enabled here. What I would like to know is similar to utkarsh's question: Is there anything I am missing in configuring my application to recognize traces? If so can you please point it out? Thanks and Regards, Sanjit Kumar [-- Attachment #2: Type: text/html, Size: 2006 bytes --]
Hello,
Copying trace framework maintainers.
On Fri, Oct 27, 2023 at 9:48 AM Sanjit Kumar
<sanjit.kumar@aviznetworks.com> wrote:
> I am trying to test the usage of the DPDK trace library. I have run into the same issue as recounted here - https://mails.dpdk.org/archives/users/2020-December/005266.html - where I am able to build and run my DPDK application where I have created and registered my custom trace point (verified via rte_trace_dump(stdout) which says my traces are 'enabled' - i see the right trace buffer size, trace file destination etc). The trace point creation and registration are identical to what is mentioned in the program guide using RTE_TRACE_POINT in a header file and registering it in my dpdk application via RTE_TRACE_POINT_REGISTER macro.
>
> What I notice are as follows:
>
> 1. The program builds and runs as intended.
> 2. The trace files are generated in the correct destination directory.
> 3. On using trace=.* ----> I see a huge list of traces on viewing the trace file with babeltrace - but do not see my custom trace point. I also do not see any trace output from my dpdk application if I reuse DPDK library traces ( eg: rte_eal_trace_thread_lcore_ready ) instead of defining my own custom traces.
> 4. On using trace=<regex for traces used in my application> i do not see any trace output just used inside my application.
>
> I think the above observations suggest that the issue might be in configuring my DPDK application to recognize and create trace output properly. However the rte_trace_dump output suggests that trace is enabled here.
>
> What I would like to know is similar to utkarsh's question:
> Is there anything I am missing in configuring my application to recognize traces? If so can you please point it out?
I think a hint was posted later, about this topic.
Did you compile your application tracepoint register code with
-DALLOW_EXPERIMENTAL_API ?
If you confirm it solves your issue, we need to enhance the trace
framework documentation.
--
David Marchand
[-- Attachment #1: Type: text/plain, Size: 2536 bytes --] Hi, Thank you for your email. I am already compiling the application that has the tracepoint register code with -DALLOW_EXPERIMENTAL_API but still am running into this issue. Are there any other possible causes for this behaviour? Thanks again. Regards, Sanjit Kumar On Fri, Oct 27, 2023 at 1:11 AM David Marchand <david.marchand@redhat.com> wrote: > Hello, > > Copying trace framework maintainers. > > On Fri, Oct 27, 2023 at 9:48 AM Sanjit Kumar > <sanjit.kumar@aviznetworks.com> wrote: > > I am trying to test the usage of the DPDK trace library. I have run into > the same issue as recounted here - > https://mails.dpdk.org/archives/users/2020-December/005266.html - where > I am able to build and run my DPDK application where I have created and > registered my custom trace point (verified via rte_trace_dump(stdout) which > says my traces are 'enabled' - i see the right trace buffer size, trace > file destination etc). The trace point creation and registration are > identical to what is mentioned in the program guide using RTE_TRACE_POINT > in a header file and registering it in my dpdk application via > RTE_TRACE_POINT_REGISTER macro. > > > > What I notice are as follows: > > > > 1. The program builds and runs as intended. > > 2. The trace files are generated in the correct destination directory. > > 3. On using trace=.* ----> I see a huge list of traces on viewing the > trace file with babeltrace - but do not see my custom trace point. I also > do not see any trace output from my dpdk application if I reuse DPDK > library traces ( eg: rte_eal_trace_thread_lcore_ready ) instead of defining > my own custom traces. > > 4. On using trace=<regex for traces used in my application> i do not see > any trace output just used inside my application. > > > > I think the above observations suggest that the issue might be in > configuring my DPDK application to recognize and create trace output > properly. However the rte_trace_dump output suggests that trace is enabled > here. > > > > What I would like to know is similar to utkarsh's question: > > Is there anything I am missing in configuring my application to > recognize traces? If so can you please point it out? > > I think a hint was posted later, about this topic. > Did you compile your application tracepoint register code with > -DALLOW_EXPERIMENTAL_API ? > > If you confirm it solves your issue, we need to enhance the trace > framework documentation. > > > -- > David Marchand > > [-- Attachment #2: Type: text/html, Size: 3125 bytes --]