On Mon, Jan 27, 2020 at 9:43 PM Aaron Conole <acon...@redhat.com> wrote: > > Jerin Jacob Kollanukkaran <jer...@marvell.com> writes: > > > Hi All, > > > > I would like to add tracing support for DPDK. > > I am planning to add this support in v20.05 release. > > > > This RFC attempts to get feedback from the community on > > > > a) Tracing Use cases. > > b) Tracing Requirements. > > b) Implementation choices. > > c) Trace format. > > > > Use-cases > > --------- > > - Most of the cases, The DPDK provider will not have access to the DPDK > > customer applications. > > To debug/analyze the slow path and fast path DPDK API usage from the field, > > we need to have integrated trace support in DPDK. > > > > - Need a low overhead Fast path multi-core PMD driver debugging/analysis > > infrastructure in DPDK to fix the functional and performance issue(s) of > > PMD. > > > > - Post trace analysis tools can provide various status across the system > > such > > as cpu_idle() using the timestamp added in the trace. > > > > > > Requirements: > > ------------- > > - Support for Linux, FreeBSD and Windows OS > > - Open trace format > > - Multi-platform Open source trace viewer > > - Absolute low overhead trace API for DPDK fast path tracing/debugging. > > - Dynamic enable/disable of trace events > > > > > > To enable trace support in DPDK, following items need to work out: > > > > a) Add the DPDK trace points in the DPDK source code. > > > > - This includes updating DPDK functions such as, > > rte_eth_dev_configure(), rte_eth_dev_start(), rte_eth_dev_rx_burst() to > > emit the trace. > > I wonder for these if it makes sense to use librte_bpf and a helper > function to actually emit events. That way rather than static trace > point data, a user can implement some C-code and pull the exact data > that they want. > > There could be some downside with the approach (because we might lose > some inlining or variable eliding), but I think it makes the trace point > concept quite a bit more powerful. Have you given it any thought?
I think the reasoning for the same to have control over whether to emit the trace or not. Right? i.e only when specific conditions are met with runtime data then only emit the trace to buffer. I think, a couple of challenges would be 1) Performance in fast-path tracing 2) Need to write eBPF class for all the events that we need to trace to have control the arguments for tracing I think, once we have the base framework in C which support enable/disable the event at runtime and then we can give provision to hook eBPF program to control more runtime nature. example emit rte_eth_dev_configure() trace only when port_id == 2 and nb_rx_q == 4.
