[dpdk-dev,v3,08/10] doc: describe Rx bytes counter behavior for enic

Message ID 20180308024702.25974-9-johndale@cisco.com (mailing list archive)
State Accepted, archived
Delegated to: Ferruh Yigit
Headers

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation success Compilation OK

Commit Message

John Daley (johndale) March 8, 2018, 2:47 a.m. UTC
  From: Hyong Youb Kim <hyonkim@cisco.com>

Signed-off-by: Hyong Youb Kim <hyonkim@cisco.com>
Reviewed-by: John Daley <johndale@cisco.com>
---
 doc/guides/nics/enic.rst | 8 ++++++++
 1 file changed, 8 insertions(+)
  

Comments

Stephen Hemminger March 8, 2018, 10:14 p.m. UTC | #1
On Wed,  7 Mar 2018 18:47:00 -0800
John Daley <johndale@cisco.com> wrote:

>      'catch-all' filters should be added last.
>  
> +- **Statistics**
> +
> +  - ``rx_good_bytes`` (ibytes) always includes VLAN header (4B) and CRC bytes (4B).
> +  - When the NIC drops a packet because the Rx queue has no free buffers,
> +    ``rx_good_bytes`` still increments by 4B if the packet is not VLAN tagged or
> +    VLAN stripping is disabled, or by 8B if the packet is VLAN tagged and stripping
> +    is enabled.

All drivers must provide consistent statistics!
That means do NOT include CRC in the rx byte counts.
Yes, several drivers in DPDK are already broken for this.

Otherwise there are cases like packets being forwarded from HW NIC to virtio and the counts
differ and customers think data is lots.
  
Hyong Youb Kim (hyonkim) March 9, 2018, 12:52 a.m. UTC | #2
On Thu, Mar 08, 2018 at 02:14:27PM -0800, Stephen Hemminger wrote:
> On Wed,  7 Mar 2018 18:47:00 -0800
> John Daley <johndale@cisco.com> wrote:
> 
> >      'catch-all' filters should be added last.
> >  
> > +- **Statistics**
> > +
> > +  - ``rx_good_bytes`` (ibytes) always includes VLAN header (4B) and CRC bytes (4B).
> > +  - When the NIC drops a packet because the Rx queue has no free buffers,
> > +    ``rx_good_bytes`` still increments by 4B if the packet is not VLAN tagged or
> > +    VLAN stripping is disabled, or by 8B if the packet is VLAN tagged and stripping
> > +    is enabled.
> 
> All drivers must provide consistent statistics!
> That means do NOT include CRC in the rx byte counts.
> Yes, several drivers in DPDK are already broken for this.
> 
> Otherwise there are cases like packets being forwarded from HW NIC to virtio and the counts
> differ and customers think data is lots.

Thanks for sharing this specific use case issue.

We are aware that our current counters are non-standard. Newer 100G
hardware models have fixed the problem (i.e. no CRC bytes, no
incrementing of bytes when no buffers). We plan to update the doc
again when we add these newer models to the supported hardware list.

As for older models, we will see if we can fix up stats in software..

-Hyong
  
Stephen Hemminger March 9, 2018, 1:48 a.m. UTC | #3
On Fri, 9 Mar 2018 09:52:54 +0900
Hyong Youb Kim <hyonkim@cisco.com> wrote:

> On Thu, Mar 08, 2018 at 02:14:27PM -0800, Stephen Hemminger wrote:
> > On Wed,  7 Mar 2018 18:47:00 -0800
> > John Daley <johndale@cisco.com> wrote:
> >   
> > >      'catch-all' filters should be added last.
> > >  
> > > +- **Statistics**
> > > +
> > > +  - ``rx_good_bytes`` (ibytes) always includes VLAN header (4B) and CRC bytes (4B).
> > > +  - When the NIC drops a packet because the Rx queue has no free buffers,
> > > +    ``rx_good_bytes`` still increments by 4B if the packet is not VLAN tagged or
> > > +    VLAN stripping is disabled, or by 8B if the packet is VLAN tagged and stripping
> > > +    is enabled.  
> > 
> > All drivers must provide consistent statistics!
> > That means do NOT include CRC in the rx byte counts.
> > Yes, several drivers in DPDK are already broken for this.
> > 
> > Otherwise there are cases like packets being forwarded from HW NIC to virtio and the counts
> > differ and customers think data is lots.  
> 
> Thanks for sharing this specific use case issue.
> 
> We are aware that our current counters are non-standard. Newer 100G
> hardware models have fixed the problem (i.e. no CRC bytes, no
> incrementing of bytes when no buffers). We plan to update the doc
> again when we add these newer models to the supported hardware list.
> 
> As for older models, we will see if we can fix up stats in software..
> 
> -Hyong

Don't worry some of the Intel drivers are buggy last I checked.
Also make sure that when forwarding that bytes transmitted == bytes received.
There were some drivers adding CRC on the receive but no on transmit.

It maybe true that you want to count CRC if the CRC stripping flag is not set.
  

Patch

diff --git a/doc/guides/nics/enic.rst b/doc/guides/nics/enic.rst
index 7e19cf88a..0bc55936a 100644
--- a/doc/guides/nics/enic.rst
+++ b/doc/guides/nics/enic.rst
@@ -310,6 +310,14 @@  Limitations
     were added. Since there currently is no grouping or priority support,
     'catch-all' filters should be added last.
 
+- **Statistics**
+
+  - ``rx_good_bytes`` (ibytes) always includes VLAN header (4B) and CRC bytes (4B).
+  - When the NIC drops a packet because the Rx queue has no free buffers,
+    ``rx_good_bytes`` still increments by 4B if the packet is not VLAN tagged or
+    VLAN stripping is disabled, or by 8B if the packet is VLAN tagged and stripping
+    is enabled.
+
 How to build the suite
 ----------------------