[dpdk-dev] Future Direction for rte_eth_stats_get()

[David Harton (dharton)]

Hi Maryam,

Thanks for the pointer.  I'll review the convo's.

Consider I have an application that uses many(all?) of the DPDK drivers and their netmap counterparts depending on configuration.  The user interface provides a set of I/O stats to help debug I/O issues and that set is the same regardless of driver type.  The set of stats provided matches what linux provides today since netmap existed before dpdk.

What I want to avoid is having an application that is driver independent having to become driver dependent interpreting a bunch of strings (from xstats) or worse the layer running at the data plane core that is advertising the API needed by the application parsing those strings because the application cannot change the upper layer.

What if instead of passing strings and values a set of stat ids and value are returned.  At least this way the application can remain driver agnostic versus having to parse a free form string that likely isn't the same across driver types.

Also, why wouldn't rte_eth_stats_get() align with linux which is the defacto standard?  I understand that not every driver may not support every stat but that's ok.  Just return 0 (pause frames, crc errors, etc).  It's not like the list of linux stats is ever growing or advertising an absurd number of stats that aren't applicable to all drivers.

Thanks again,
Dave

> -----Original Message-----
> From: Tahhan, Maryam [mailto:maryam.tahhan at intel.com]
> Sent: Friday, January 22, 2016 6:08 AM
> To: David Harton (dharton) <dharton at cisco.com>; dev at dpdk.org
> Subject: RE: Future Direction for rte_eth_stats_get()
> 
> Hi David
> Some of the stats were HW specific rather than generic stats that should
> be exposed through rte_eth_stats and were migrated to the xstats API.
> http://dpdk.org/ml/archives/dev/2015-June/019915.html. The naming was also
> not generic enough to cover some of the drivers and in some cases what was
> exposed was only a partial view of the relevant stats.
> 
> They were marked as deprecated to deter people from using them in the
> future, but haven't been removed from all the driver implementations yet.
> The Registers that remain undeprecated are those considered to be generic.
> 
> Which registers are you particularly interested in that have been
> deprecated? Can you elaborate on what you mean by " scenarios where a
> static view is expected "
> 
> Thanks in advance.
> 
> Best Regards,
> Maryam
> 
> 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of David Harton
> > (dharton)
> > Sent: Wednesday, January 20, 2016 5:19 PM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] Future Direction for rte_eth_stats_get()
> >
> > I see that some of the rte_eth_stats have been marked deprecated in 2.2
> > that are returned by rte_eth_stats_get().  Applications that utilize any
> > number of device types rely on functions like this one to debug I/O
> > issues.
> >
> > Is there a reason the stats have been deprecated?  Why not keep the
> > stats in line with the standard linux practices such as
> rtnl_link_stats64?
> >
> > Note, using rte_eth_xstats_get() does not help for this particular
> scenario
> > because a common binary API is needed to communicate through
> > various layers and also provide a consistent view/meaning to users.  The
> > xstats is excellent for debugging device specific scenarios but can't
> help
> > in scenarios where a static view is expected.
> >
> > Thanks,
> > Dave