[dpdk-dev] [PATCH v3 00/11] Port XStats

[Van Haaren, Harry]

Hi All,

(Please keep everyone on To/CC - a few people were dropped)


Note: During my writing a reply to Kyle, Thomas has also replied to Kyle.


> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Kyle Larose
> Sent: Thursday, October 29, 2015 12:55 PM
> To: Tom Crugnale; Stephen Hemminger
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 00/11] Port XStats

> Ultimately the issue we are trying to solve is that there is no device
> independent way to get any detailed statistics from NICs controlled by
> DPDK. These statistics are quite useful, not just for diagnostics, but
> for long term reporting. People using DPDK-based NFV products in a
> production environment are not going to be happy that they cannot, for
> example, see how the packet size bucket counters varied over time
> using some sort of monitoring tool.

Agreed, and that's what the xstats solves.


> So, let's consider solving the problem within DPDK. One option is to
> use well-defined names for a given xstat that has the same semantics
> across NICs, while continuing to allow NICs to expose any stats that
> don't fall into this category.

Yes, this is the aim of the current xstats also. As Tom Crugnale pointed
out, the current implementation has some variation in string names, however
the end-goal is to have consistent naming across NICs.

The scheme for naming stats is described in a doc patch, which was part
of my patchset: http://dpdk.org/dev/patchwork/patch/7906/

Ideally a script will automatically checks stats names against those of
other NICs, allowing switching of NICs and stats remaining consistent.

Given that each NIC is unique, this will require some organization work,
but it seems possible with some collaboration.


> Another option is to provide an API with a well-defined set of stats,
> perhaps using an enum. In order for a stat to be added to this list,
> it needs to be part of a standard (such as
> http://tools.ietf.org/html/rfc2819).

I would prefer see xstats gain wider support instead of discussing other
options. 


> Does anybody else see the need for something like this?
Yes.


Cheers, -Harry