From: "Zhao1, Wei" <wei.zhao1@intel.com>
To: Kyle Larose <eomereadig@gmail.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v2] net/i40e: fix Rx statistic inconsistent
Date: Mon, 1 Aug 2016 08:58:22 +0000 [thread overview]
Message-ID: <A2573D2ACFCADC41BB3BE09C6DE313CA01F84A14@PGSMSX103.gar.corp.intel.com> (raw)
In-Reply-To: <CAMFWN9mU7_NekFioMUMOkTER=MWihuHo2Ksk7gF-6W86dwnRxA@mail.gmail.com>
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.
-----Original Message-----
From: Kyle Larose [mailto:eomereadig@gmail.com]
Sent: Saturday, July 30, 2016 1:17 AM
To: Zhao1, Wei <wei.zhao1@intel.com>
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 <wei.zhao1@intel.com> wrote:
> 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 <wei.zhao1@intel.com>
> ---
> 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.
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->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?
next prev parent reply other threads:[~2016-08-01 8:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-29 8:50 Wei Zhao1
2016-07-29 17:16 ` Kyle Larose
2016-08-01 8:58 ` Zhao1, Wei [this message]
2016-08-02 3:27 ` Zhao1, Wei
2016-08-02 6:59 ` Zhao1, Wei
2016-08-02 16:22 ` Kyle Larose
2016-08-09 2:18 ` Zhao1, Wei
2016-08-22 11:10 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=A2573D2ACFCADC41BB3BE09C6DE313CA01F84A14@PGSMSX103.gar.corp.intel.com \
--to=wei.zhao1@intel.com \
--cc=dev@dpdk.org \
--cc=eomereadig@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).