[dpdk-dev,v2,01/11] doc: add extended statistics notes

  Add release notes for this patchset.

Signed-off-by: Harry van Haaren <harry.van.haaren@intel.com>
---
 doc/guides/rel_notes/release_2_2.rst | 12 ++++++++++++
 1 file changed, 12 insertions(+)
  

This patchset adds an implementation of the xstats_get() and xstats_reset() API
to the following PMDs: virtio, igb, igbvf, ixgbe, ixgbevf, i40e, i40evf and
fm10k.

The xstats API allows DPDK apps to gain access to extended statistics from each
port on a NIC. These statistics are structured as per a scheme detailed in the
patch for the doc/prog_guide.


Harry van Haaren (11):
  doc: add extended statistics notes
  doc: add extended statistics to prog_guide
  ethdev: update xstats_get() strings and Q handling
  virtio: add xstats() implementation
  igb: add xstats() implementation
  igbvf: add xstats() implementation
  ixgbe: update statistic strings to scheme
  ixgbevf: add xstats() functions to VF
  i40e: add xstats() implementation
  i40evf: add xstats() implementation
  fm10k: add xstats() implementation

 doc/guides/prog_guide/poll_mode_drv.rst |  51 ++++-
 doc/guides/rel_notes/release_2_2.rst    |  12 ++
 drivers/net/e1000/igb_ethdev.c          | 194 +++++++++++++++++-
 drivers/net/fm10k/fm10k_ethdev.c        |  87 ++++++++
 drivers/net/i40e/i40e_ethdev.c          | 265 +++++++++++++++++++++++-
 drivers/net/i40e/i40e_ethdev_vf.c       |  89 +++++++-
 drivers/net/ixgbe/ixgbe_ethdev.c        | 346 +++++++++++++++++++++++++++++---
 drivers/net/virtio/virtio_ethdev.c      |  98 ++++++++-
 drivers/net/virtio/virtio_rxtx.c        |  32 +++
 drivers/net/virtio/virtqueue.h          |   4 +
 lib/librte_ether/rte_ethdev.c           |  38 ++--
 11 files changed, 1154 insertions(+), 62 deletions(-)
  

Hi Harry,

We are planning on using the xstats API for periodic stats collection through a polling thread.  This would be done in a generic NIC agnostic manner, which would require that the xstats identifiers have consistent naming amongst all of the NIC types.  It would likely be polled several times per second and would only gather a subset of all available xstats types.  

I have reviewed your patches and am interested in providing some API enhancements and bugfixes.  Are you willing to provide feedback on such changes?

Thank you,
Tom

-----Original Message-----
From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Harry van Haaren
Sent: Thursday, October 22, 2015 11:48 AM
To: dev@dpdk.org
Subject: [dpdk-dev] [PATCH v3 00/11] Port XStats

This patchset adds an implementation of the xstats_get() and xstats_reset() API to the following PMDs: virtio, igb, igbvf, ixgbe, ixgbevf, i40e, i40evf and fm10k.

The xstats API allows DPDK apps to gain access to extended statistics from each port on a NIC. These statistics are structured as per a scheme detailed in the patch for the doc/prog_guide.


Harry van Haaren (11):
  doc: add extended statistics notes
  doc: add extended statistics to prog_guide
  ethdev: update xstats_get() strings and Q handling
  virtio: add xstats() implementation
  igb: add xstats() implementation
  igbvf: add xstats() implementation
  ixgbe: update statistic strings to scheme
  ixgbevf: add xstats() functions to VF
  i40e: add xstats() implementation
  i40evf: add xstats() implementation
  fm10k: add xstats() implementation

 doc/guides/prog_guide/poll_mode_drv.rst |  51 ++++-
 doc/guides/rel_notes/release_2_2.rst    |  12 ++
 drivers/net/e1000/igb_ethdev.c          | 194 +++++++++++++++++-
 drivers/net/fm10k/fm10k_ethdev.c        |  87 ++++++++
 drivers/net/i40e/i40e_ethdev.c          | 265 +++++++++++++++++++++++-
 drivers/net/i40e/i40e_ethdev_vf.c       |  89 +++++++-
 drivers/net/ixgbe/ixgbe_ethdev.c        | 346 +++++++++++++++++++++++++++++---
 drivers/net/virtio/virtio_ethdev.c      |  98 ++++++++-
 drivers/net/virtio/virtio_rxtx.c        |  32 +++
 drivers/net/virtio/virtqueue.h          |   4 +
 lib/librte_ether/rte_ethdev.c           |  38 ++--
 11 files changed, 1154 insertions(+), 62 deletions(-)

--
1.9.1
  

On Wed, 28 Oct 2015 17:35:09 +0000
Tom Crugnale <tcrugnale@sandvine.com> wrote:

> Hi Harry,
> 
> We are planning on using the xstats API for periodic stats collection through a polling thread.  This would be done in a generic NIC agnostic manner, which would require that the xstats identifiers have consistent naming amongst all of the NIC types.  It would likely be polled several times per second and would only gather a subset of all available xstats types.  
> 
> I have reviewed your patches and am interested in providing some API enhancements and bugfixes.  Are you willing to provide feedback on such changes?
> 
> Thank you,
> Tom

The whole point of xstats is to allow device specific statistics.
Consistent use of names is good from a user interface point of view, but probably
not a hard requirement.
  

I understand.  Is this the reason that that strings were used to identify the xstat types?  An enum type would be much more efficient instead of doing string copies when retrieving the stats, but the number of enum entries would quickly grow out of control as device specific stats were added.

In this case, I'm actually referring to the stats that are common to all NICs.  For example, for the received fragmented packets counter, there are three strings that identify this value: rx_fragment_packets (igb), rx_fragment_errors (ixgbe), rx_fragmented_packets (i40e).
I was thinking of making those names consistent.  Perhaps the reason why they were different in the first place is that each of the device datasheets refers to these exact names.

Tom

-----Original Message-----
From: Stephen Hemminger [mailto:stephen@networkplumber.org] 
Sent: Wednesday, October 28, 2015 5:32 PM
To: Tom Crugnale
Cc: Harry van Haaren; dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v3 00/11] Port XStats

On Wed, 28 Oct 2015 17:35:09 +0000
Tom Crugnale <tcrugnale@sandvine.com> wrote:

> Hi Harry,
> 
> We are planning on using the xstats API for periodic stats collection through a polling thread.  This would be done in a generic NIC agnostic manner, which would require that the xstats identifiers have consistent naming amongst all of the NIC types.  It would likely be polled several times per second and would only gather a subset of all available xstats types.  
> 
> I have reviewed your patches and am interested in providing some API enhancements and bugfixes.  Are you willing to provide feedback on such changes?
> 
> Thank you,
> Tom

The whole point of xstats is to allow device specific statistics.
Consistent use of names is good from a user interface point of view, but probably not a hard requirement.
  

Stephen,

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.

The only alternative I can see to providing an API within DPDK is to
build our own abstraction layer triggered off the driver name/pci
ids/etc. I expect other people would end up doing this as well. This
seems like a waste of effort when an abstraction layer already exists
within DPDK.

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.

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).

Does anybody else see the need for something like this? We're more
than willing to do the work. We'd like to make sure we have the right
API, though.

Thanks,

Kyle

On Wed, Oct 28, 2015 at 8:55 PM, Tom Crugnale <tcrugnale@sandvine.com> wrote:
> I understand.  Is this the reason that that strings were used to identify the xstat types?  An enum type would be much more efficient instead of doing string copies when retrieving the stats, but the number of enum entries would quickly grow out of control as device specific stats were added.
>
> In this case, I'm actually referring to the stats that are common to all NICs.  For example, for the received fragmented packets counter, there are three strings that identify this value: rx_fragment_packets (igb), rx_fragment_errors (ixgbe), rx_fragmented_packets (i40e).
> I was thinking of making those names consistent.  Perhaps the reason why they were different in the first place is that each of the device datasheets refers to these exact names.
>
> Tom
>
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Wednesday, October 28, 2015 5:32 PM
> To: Tom Crugnale
> Cc: Harry van Haaren; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 00/11] Port XStats
>
> On Wed, 28 Oct 2015 17:35:09 +0000
> Tom Crugnale <tcrugnale@sandvine.com> wrote:
>
>> Hi Harry,
>>
>> We are planning on using the xstats API for periodic stats collection through a polling thread.  This would be done in a generic NIC agnostic manner, which would require that the xstats identifiers have consistent naming amongst all of the NIC types.  It would likely be polled several times per second and would only gather a subset of all available xstats types.
>>
>> I have reviewed your patches and am interested in providing some API enhancements and bugfixes.  Are you willing to provide feedback on such changes?
>>
>> Thank you,
>> Tom
>
> The whole point of xstats is to allow device specific statistics.
> Consistent use of names is good from a user interface point of view, but probably not a hard requirement.
>
  

2015-10-29 08:55, Kyle Larose:
> 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.

I don't understand.
The basic statistics are provided in a common API.
The other ones are not available in every NICs and can only be interpreted
while knowing the device. So what is the need exactly?
Do you know an example of a networking layer having this kind of API?
  

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@dpdk.org] On Behalf Of Kyle Larose

> Sent: Thursday, October 29, 2015 12:55 PM

> To: Tom Crugnale; Stephen Hemminger

> Cc: dev@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
  

On Thu, Oct 29, 2015 at 9:10 AM, Thomas Monjalon
<thomas.monjalon@6wind.com> wrote:

> I don't understand.
> The basic statistics are provided in a common API.
> The other ones are not available in every NICs and can only be interpreted
> while knowing the device. So what is the need exactly?

The need is to provide information to users about what sort of traffic
is being seen by the device, and why the hardware is behaving the way
it is, leveraging as much as possible the capabilities of the hardware
with minimal effort (i.e. not implementing an abstraction layer at a
higher level).

These are quite useful for diagnosing wider network issues
(configuration, misbehaving devices, dirty fibers/etc). The common API
doesn't expose the more detailed information requested by the various
ethernet mibs. Of course, not all stats are applicable to all devices
(e.g. collisions), but those that are available are still invaluable.

> Do you know an example of a networking layer having this kind of API?

I have worked with SDKs for a few different physical switches and
NPUs. They all provide this sort of API. I think it is quite common
with networking equipment such as routers or switches. These stats
tend to be exposed over SNMP at the very least, and often within local
utilities on the devices themselves.

Thanks,

Kyle
  

2015-10-29 09:57, Kyle Larose:
> On Thu, Oct 29, 2015 at 9:10 AM, Thomas Monjalon
> <thomas.monjalon@6wind.com> wrote:
> 
> > I don't understand.
> > The basic statistics are provided in a common API.
> > The other ones are not available in every NICs and can only be interpreted
> > while knowing the device. So what is the need exactly?
> 
> The need is to provide information to users about what sort of traffic
> is being seen by the device, and why the hardware is behaving the way
> it is, leveraging as much as possible the capabilities of the hardware
> with minimal effort (i.e. not implementing an abstraction layer at a
> higher level).
> 
> These are quite useful for diagnosing wider network issues
> (configuration, misbehaving devices, dirty fibers/etc). The common API
> doesn't expose the more detailed information requested by the various
> ethernet mibs. Of course, not all stats are applicable to all devices
> (e.g. collisions), but those that are available are still invaluable.

Thanks for the explanation.

> > Do you know an example of a networking layer having this kind of API?
> 
> I have worked with SDKs for a few different physical switches and
> NPUs. They all provide this sort of API. I think it is quite common
> with networking equipment such as routers or switches. These stats
> tend to be exposed over SNMP at the very least, and often within local
> utilities on the devices themselves.

So what is missing currently? Just having a consistent naming of
similar counters?
  

On Thu, Oct 29, 2015 at 10:01 AM, Thomas Monjalon
<thomas.monjalon@6wind.com> wrote:

> So what is missing currently? Just having a consistent naming of
> similar counters?

A consistent naming scheme would certainly solve the problem.

Thanks again,

Kyle