Hello, Copying trace framework maintainers.
On Fri, Oct 27, 2023 at 9:48 AM Sanjit Kumar <[email protected]> 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
