<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() Agreed. Currently, using app/proc-info does not provide this ability. We cannot add this capability to app/proc-info as these stats would be specific to L3fwd application.
> > 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 This is good for analyzing an incident. I think it is an overhead for development purposes. > > > > ability to easily change parameters without having to recompile, which > > helps reduce debugging time significantly.
