Hi, Wujingjing and Kyle Larose 

-----Original Message-----
From: Zhao1, Wei
Sent: Tuesday, August 2, 2016 11:27 AM
To: Wu, Jingjing <redacted>; Lu, Wenzhuo
[off-list ref]
Cc: dev@dpdk.org
Subject: RE: [dpdk-dev] [PATCH v2] net/i40e: fix Rx statistic inconsistent

Hi,Wu jingjing and wenzhuo

quoted

-----Original Message-----
From: Zhao1, Wei
Sent: Monday, August 1, 2016 4:58 PM
To: 'Kyle Larose' <redacted>
Cc: dev@dpdk.org
Subject: RE: [dpdk-dev] [PATCH v2] net/i40e: fix Rx statistic
inconsistent

Hi, Kyle Larose
   The core problem is i40e has no statistic of discard bytes, that
means even if when ports are not stopped, the statistic  rx_good_bytes
is consist of discard
bytes，is that reasonable? In other words, I can just minus discard
bytes from rx_good_bytes if I can get discard bytes number, that is much

better.

quoted

-----Original Message-----
From: Kyle Larose [mailto:eomereadig@gmail.com]
Sent: Saturday, July 30, 2016 1:17 AM
To: Zhao1, Wei <redacted>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2] net/i40e: fix Rx statistic
inconsistent

On Fri, Jul 29, 2016 at 4:50 AM, Wei Zhao1 [off-list ref] wrote:

quoted

rx_good_bytes and rx_good_packets statistic is inconsistent when
port stopped,ipackets statistic is minus the discard packets but
rx_bytes statistic not.Also,i40e has no statistic of discard bytes,
so we have to delete discard packets item from rx_good_packets statistic.

Fixes: 9aace75fc82e ("i40e: fix statistics")

Signed-off-by: Wei Zhao1 <redacted>
---
 drivers/net/i40e/i40e_ethdev.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev.c

b/drivers/net/i40e/i40e_ethdev.c index 11a5804..553dfd9 100644

--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c

@@ -2319,8 +2319,7 @@ i40e_dev_stats_get(struct rte_eth_dev *dev,

struct rte_eth_stats *stats)

        stats->ipackets = pf->main_vsi->eth_stats.rx_unicast +
                        pf->main_vsi->eth_stats.rx_multicast +
-                       pf->main_vsi->eth_stats.rx_broadcast -
-                       pf->main_vsi->eth_stats.rx_discards;
+                       pf->main_vsi->eth_stats.rx_broadcast;
        stats->opackets = pf->main_vsi->eth_stats.tx_unicast +
                        pf->main_vsi->eth_stats.tx_multicast +
                        pf->main_vsi->eth_stats.tx_broadcast;
--
2.5.5

Is it not worse to report a received packet when no packet was
actually received by the upper layers under normal operations than to
ensure that packets and  bytes are consistent when an interface is
stopped? It seems like the first case is much more likely to occur than the

second.

quoted

Are we just introducing a new issue to fix another?

How does this behaviour compare to other NICs? Does the ixgbe report
discarded packets in its ipackets? My reading of the driver is that it does not.
In fact, it does something interesting to deal with the
problem:

from:
http://dpdk.org/browse/dpdk/tree/drivers/net/ixgbe/ixgbe_ethdev.c

/*
* An errata states that gprc actually counts good + missed packets:
* Workaround to set gprc to summated queue packet receives */
hw_stats-

quoted

gprc = *total_qprc;

total_gprc is equal to the sum of the qprc per queue. Can we do
something similar on the i40e instead of adding unicast, mulitcast and

broadcast?


I have checked ixgbe code about  Rx statistic, in function
ixgbe_read_stats_registers() we can find the rx_good_bytes and
rx_good_packets statistic.
It is listed below, we  can see rx_good_packets is also just addition of Queue
Packets Received Count and  not minused  discard packet number.
Is there some wrong of understanding?

for (i = 0; i < IXGBE_QUEUE_STAT_COUNTERS; i++) {
......
                                 *total_qprc += hw_stats->qprc[i];
		*total_qbrc += hw_stats->qbrc[i];
......
}

   The problem is i40e has no statistic of discard bytes, so it is impossible to minus discard bytes from rx_good_bytes . If you think it's not reasonable to 
Delete  rx_discards iterm from rx_good_packets statistic, this patch will be superseded. Because I didn't find other way to correct this problem at present.