> From: Jerin Jacob [mailto:jerinjac...@gmail.com]
>
> On Mon, Aug 19, 2024 at 4:13 PM Ferruh Yigit <ferruh.yi...@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. :-)
