On Thu, Apr 1, 2021 at 2:05 AM Kathleen Capella <kathleen.cape...@arm.com> wrote: > > > > > -----Original Message----- > > From: Honnappa Nagarahalli <honnappa.nagaraha...@arm.com> > > Sent: Thursday, March 11, 2021 11:00 AM > > To: tho...@monjalon.net > > Cc: Jerin Jacob <jerinjac...@gmail.com>; dev@dpdk.org; Kathleen Capella > > <kathleen.cape...@arm.com>; Dharmik Thakkar > > <dharmik.thak...@arm.com>; Ruifeng Wang <ruifeng.w...@arm.com>; > > david.march...@redhat.com; Bruce Richardson > > <bruce.richard...@intel.com>; jer...@marvell.com; > > hemant.agra...@nxp.com; Ferruh Yigit <ferruh.yi...@intel.com>; Ananyev, > > Konstantin <konstantin.anan...@intel.com>; Stephen Hemminger > > <sthem...@microsoft.com>; nd <n...@arm.com>; nd <n...@arm.com> > > Subject: RE: [dpdk-dev] L3fwd mode in testpmd > > > > <snip> > > > > > > > > > > > > > > > > On Thu, Mar 11, 2021 at 12:01 AM Honnappa Nagarahalli > > > > > <honnappa.nagaraha...@arm.com> wrote: > > > > > > > > > > > > Hello, > > > > > > Performance of L3fwd example application is one of the > > > > > > key > > > > > benchmarks in DPDK. However, the application does not have many > > > > > debugging statistics to understand the performance issues. We have > > > > > added L3fwd as another mode/stream to testpmd which provides > > > enough > > > > > statistics at various levels. This has allowed us to debug the > > > > > performance issues effectively. > > > > > > > > > > > > There is more work to be done to get it to upstreamable state. I > > > > > > am > > > > > wondering if such a patch is helpful for others and if the > > > > > community would be interested in taking a look. Please let me know > > what you think. > > > > > > > > > > We are using app/proc-info/ to attach and analyze the performance. > > > > > That helps to analyze the unmodified application. I think, if > > > > > something is missing in proc-info app, in my opinion it is better > > > > > to enhance proc-info so that it can help other third-party > > > > > applications. > > > > > > > > > > Just my 2c. > > > > Thanks Jerin. We will explore that. > > > > > > I agree it is dangerous to rely too much on testpmd for everything. > > > Please tell us what in testpmd could be useful out of it. > > > > > Things that are very helpful in testpmd are: 1) HW statistics from the NIC > > 2) > > Forwarding stats 3) Burst stats (indication of headroom availability) 4) > > Easy to > > set parameters like RX and TX queue depths (among others) without having > > to recompile. > > [Kathleen Capella] > Thank you for the suggestion of app/proc-info. I've tried it out with > l3fwd and see that it does have the HW stats from the NIC and the forwarding > stats. > However, it does not have the burst stats testpmd offers, nor the
One option to see such level of debugging would be to have - Create a memzone in the primary process - Application under test can update the stats in memzone based on the code flow - proc-info can read the counters updated by application under test using the memzone object got through rte_memzone_lookup() Another approach will be using rte_trace()[1] for debugging/tracing by adding tracepoints in l3fwd for such events. It has a timestamp and the trace format is opensource trace format(CTF(Common trace format)), so that we can use post posting tools to analyze. [1] https://doc.dpdk.org/guides/prog_guide/trace_lib.html > ability to easily change parameters without having to recompile, > which helps reduce debugging time significantly.
