Ethdev tracepoints optimization

[Morten Brørup]

> From: Jerin Jacob [mailto:jerinjacobk at gmail.com]
> 
> On Mon, Aug 19, 2024 at 4:13 PM Ferruh Yigit <ferruh.yigit at amd.com> wrote:
> >
> > On 8/15/2024 8:32 PM, Adel Belkhiri wrote:
> > > Hi DPDK Community,
> > >
> > > I am currently working on developing performance analyses for
> > > applications using the ethdev library. These analyses are being
> > > implemented in Trace Compass, an open-source performance analyzer. One
> > > of the views I’ve implemented shows the rate of traffic received or sent
> > > by an ethernet port, measured in packets per second. However, I've
> > > encountered an issue with the lib.ethdev.rx.burst event, which triggers
> > > even when no packets are polled, leading to a significant number of
> > > irrelevant events in the trace. This becomes problematic as these
> > > "empty" events can overwhelm the tracer buffer, potentially causing the
> > > loss of more critical events due to their high frequency.
> > >
> > > To address this, I've modified the DPDK code in lib/ethdev/rte_ethdev.h
> > > to add a conditional statement that only triggers the event when nb_rx >
> > > 0. My question to the community is whether there are use cases where an
> > > "empty" lib.ethdev.rx.burst event could be useful. If not, would there
> > > be interest in submitting a patch with this modification?
> > >
> >
> > Tracepoint is good way to get frequency of the calls, so I believe there
> > can be value of getting empty burst calls too.

Agree. The trace cannot generally omit empty burst calls.

> >
> > But your usecase also a valid one. I wonder if it works to have separate
> > trace calls, for empty and non-empty ones, and how this additional
> > branching impacts the performance, at least branch should be wrapped
> > with 'RTE_ENABLE_TRACE_FP' macro to not impact non-tracing usage.
> 
> 
> CTF(Common trace format) post processing tools can check the value for
> each field and timestap.
> So it will easy to skip the ones with no packet for this case.

Doesn't solve the issue of the tracer itself being overwhelmed.

Although I like Bruce's suggestion, which somewhat resembles Linux Kernel logging, I fear that it might be incompatible with automated tools processing the trace files afterwards.

I think Ferruh's suggestion should work:

Replace the current trace point with two separate trace points for respectively empty and non-empty calls:

RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_rx_burst_empty,
	lib.ethdev.rx.burst.empty)

RTE_TRACE_POINT_REGISTER(rte_ethdev_trace_rx_burst_nonempty,
	lib.ethdev.rx.burst.nonempty)

And update the code in lib/ethdev/rte_ethdev.h to call the appropriate of the two functions depending on nb_rx.


PS: Something similar could be added to the eventdev library's rte_event_dequeue_burst() function. But that's a task for another day. :-)