Hi, 03/04/2020 17:36, [email protected]: > Features: > ~~~~~~~~~ > - APIs and Features are similar to rte_log dynamic framework > API(expect log prints on stdout vs it dumps on trace file)
A log can print to syslog as well. As discussed somewhere else, please do not introduce global level in rte_trace. I think it is useless. If we need to change the level of all trace types, we can just use a wildcard (globbing or regexp). And about wording, "pattern" is too vague and should be replaced with "globbing". > - No specific limit on the events. A string-based event like rte_log > for pattern matching Would it be possible to replace rte_log with rte_trace? > - Dynamic enable/disable support. How dynamic it is? Can we start/stop a trace after starting DPDK? I think we need a control channel for this. I propose to introduce a general control channel in DPDK. > - Instructmention overhead is ~1 cycle. i.e cost of adding the code Nice > wth out using trace feature. > - Timestamp support for all the events using DPDK rte_rtdsc Could we use other timestamp sources, like the mbuf timestamp for Rx traces? > - No dependency on another library. Clean room native implementation of > CTF. No benefit of using an external CTF library maintained somewhere else?
