[ovs-dev] [PATCH v2] netdev: Custom statistics.

[Weglicki, MichalX]

> -----Original Message-----
> From: Kevin Traynor [mailto:ktraynor at redhat.com]
> Sent: Monday, January 8, 2018 7:08 PM
> To: Weglicki, MichalX <michalx.weglicki at intel.com>; dev at openvswitch.org
> Subject: Re: [ovs-dev] [PATCH v2] netdev: Custom statistics.
> 
> On 12/19/2017 03:00 PM, Kevin Traynor wrote:
> > On 12/19/2017 02:35 PM, Weglicki, MichalX wrote:
> >>> -----Original Message-----
> >>> From: Kevin Traynor [mailto:ktraynor at redhat.com]
> >>> Sent: Tuesday, December 19, 2017 3:07 PM
> >>> To: Weglicki, MichalX <michalx.weglicki at intel.com>; dev at openvswitch.org
> >>> Subject: Re: [ovs-dev] [PATCH v2] netdev: Custom statistics.
> >>>
> >>> On 12/05/2017 02:55 PM, Michal Weglicki wrote:
> >>>> - New get_custom_stats interface function is added to netdev. It
> >>>>   allows particular netdev implementation to expose custom
> >>>>   counters in dictionary format (counter name/counter value).
> >>>> - New statistics are retrieved using experimenter code and
> >>>>   are printed as a result to ofctl dump-ports.
> >>>> - New counters are available for OpenFlow 1.4+.
> >>>> - New statistics are printed to output via ofctl only if those
> >>>>   are present in reply message.
> >>>> - New statistics definition is added to include/openflow/intel-ext.h.
> >>>> - Custom statistics are implemented only for dpdk-physical
> >>>>   port type.
> >>>> - DPDK-physical implementation uses xstats to collect statistics.
> >>>>   Only dropped and error counters are exposed.
> >>>>
> >>> Hi Michal - why only dropped and error counters? why not just expose
> >>> them all. For example, IIUC this would report management dropped packets
> >>> but there would not be a stat for management rx/tx successful packets.
> >>>
> >>> Kevin.
> >> Hi Kevin - those counters were of biggest value to us at the point of making this
> >> patch, sending all counters (where for IXGBE is about 150) will produce
> >> some movement on the network. I think that biggest advantage of this
> >> particular patch is that it introduces a mechanism to expose
> >> any counters, counters list can be extended in the future
> >> if necessary. However I'm not sure if sending all counters
> >> is good idea, as there could be thousands of it in the future - in this
> >> solution, we have some kind of control over the data size.
> >>
> > Ok thanks, that makes sense. I would like to suggest that *_management_*
> > be added as part of this as I think it's only 2 additional stats and
> > I've seen at least one user saying they needed this information.
> >
> 
> Hi Michal, this does not look to be in v3, do you think it should be
> added as a separate patch? or they should not be reported?
So sorry Kevin, I've simply forgot to add it, I've just sent v4
where those counters are included. 

> 
> thanks,
> Kevin.
> 
>