From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f195.google.com (mail-io0-f195.google.com [209.85.223.195]) by dpdk.org (Postfix) with ESMTP id 8F8D52BDA for ; Tue, 2 Aug 2016 18:22:26 +0200 (CEST) Received: by mail-io0-f195.google.com with SMTP id y195so16389377iod.0 for ; Tue, 02 Aug 2016 09:22:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=s3ZDD3t612KLhQffpmuyUneNQkFzqr9o2zWNESun/8E=; b=Lt+PBIMwl+Q9MwImZ0uDm4THtzB4hA4/oN12rHRRNAaugVwXyG5YqcbjBf1Qwjl/3D 3lqLB7yWWYR8aPVo0ZkK7Zbz6ovrxn3fdIo6kcQLOhGXA1IREm8oUX8gUtPjPNQHZzoh xIqGeriLg+EWHfP3smtXUTI/rxpwOOjILCOYas4prLXGZ4Z9+k40Mxw/hGisLTcjdYY8 aqCFBp8Gtzb5RXZDmpv1w26nRPgcWZHjMUF327CCosD8mLgjRLv+AoDWPlOOocCOPVw9 IlqzPV4Y5U0SdOzNEEvWXvWBZoADjWm0aBQFSi8irLrD99bWIoth5zkCscDJrdm1zBEt ZVtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=s3ZDD3t612KLhQffpmuyUneNQkFzqr9o2zWNESun/8E=; b=Z+4LKUQQmXb2SduRugzZyl4kHtuSMW+LMcscHQGmlaZKWrht78d+tNOwf1Y4lx5a+B xkC5VlUHeIqP6QKkx8mixt6gxmGBLCk++r/lBXO1IX/Fcf7WzwG05vs7EkfYDQCiNCRO E/geeFOYPjz1rmYYcEi7CLn66v03Dl/8PKFqeGKpOcF72352LLp/m5mp6dg8ASacNZv5 j8NiqlgxYN2nSb6x2WpP71o1sDMPcKvmXflH1/icrThEI9OcLS38z2GhSfX93HYp4q87 UuP720d6A44a2LDOJaQKOEJnRCg6aSMyN3TddTaVk6FzC5npB31YcSa7hIOFGBeK20G8 NcIg== X-Gm-Message-State: AEkoouuizVTo+xiE59Fojr120H2fKQ5/4Z54xd8bXKNb+B03rO7MXkWxCc3N5I0i75gmCMZpXqCXaemMSfO9iA== X-Received: by 10.107.51.149 with SMTP id z143mr62950957ioz.176.1470154945993; Tue, 02 Aug 2016 09:22:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.10.103 with HTTP; Tue, 2 Aug 2016 09:22:25 -0700 (PDT) In-Reply-To: References: <1469782239-48758-1-git-send-email-wei.zhao1@intel.com> From: Kyle Larose Date: Tue, 2 Aug 2016 12:22:25 -0400 Message-ID: To: "Zhao1, Wei" Cc: "Wu, Jingjing" , "dev@dpdk.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v2] net/i40e: fix Rx statistic inconsistent X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 16:22:26 -0000 Hello Wei, On Tue, Aug 2, 2016 at 2:59 AM, Zhao1, Wei wrote: > Hi, Wujingjing and Kyle Larose > > > >> -----Original Message----- >> From: Zhao1, Wei >> Sent: Tuesday, August 2, 2016 11:27 AM >> To: Wu, Jingjing ; Lu, Wenzhuo >> >> Cc: dev@dpdk.org >> Subject: RE: [dpdk-dev] [PATCH v2] net/i40e: fix Rx statistic inconsiste= nt >> >> Hi,Wu jingjing and wenzhuo >> >> > -----Original Message----- >> > From: Zhao1, Wei >> > Sent: Monday, August 1, 2016 4:58 PM >> > To: 'Kyle Larose' >> > 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=EF=BC=8Cis that reasonable? In other words, I can just minus dis= card >> > bytes from rx_good_bytes if I can get discard bytes number, that is mu= ch >> better. >> > >> > -----Original Message----- >> > From: Kyle Larose [mailto:eomereadig@gmail.com] >> > Sent: Saturday, July 30, 2016 1:17 AM >> > To: Zhao1, Wei >> > 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 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 stati= stic. >> > > >> > > Fixes: 9aace75fc82e ("i40e: fix statistics") >> > > >> > > Signed-off-by: Wei Zhao1 >> > > --- >> > > 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 =3D 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 =3D 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 tha= n 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 =3D *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? My understanding of the problem can be broken into three parts: 1) In Unicast/Multicast/Broadcast packet counters are counting packets which were discarded 2) The corresponding byte counters count packets which were discarded. 3) There are no discarded byte counters. Our in bytes counter consists of the sum of in unicast, in multicast, and in broadcast. This sum includes discarded bytes, which we do not want, for two reasons. First, it would lead to misleading bitrate reports: people expect to see the amount of traffic actually handled. Second, it conflicts with the current packet counters (the counters without your change). Obviously if we could count the discarded bytes, we could subtract them. Alternatively, if we could count only received bytes which were not discarded, then we would not need to subtract discarded bytes from the received bytes counter. The ixgbe had a similar problem for packets, but presumably not bytes. So, I looked to it for inspiration. Presumably, the ixgbe per-queue counters count all received packets, per queue, and do not count discarded packets.Thus, is you take the sum of received packets across all queues, you can find the total number of received packets without discards included. Can we not do the same thing on the i40e, but for bytes? I just took a quick look at the datasheet, and I cannot see anything offhand that is equivalent to qbrc, which is what I would have used here. That said, I'm not an i40e expert, so I may have missed something. That's why I'm asking if it's possible. :) >> >> for (i =3D 0; i < IXGBE_QUEUE_STAT_COUNTERS; i++) { >> ...... >> *total_qprc +=3D hw_stats->qprc[i]; >> *total_qbrc +=3D hw_stats->qbrc[i]; >> ...... >> } > > The problem is i40e has no statistic of discard bytes, so it is imposs= ible to minus discard bytes from rx_good_bytes . If you think it's not reas= onable 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. > I understand that there is no discard byte counter. Are there per-queue byte counters on the i40e, which do not count discarded byte, with which we could do a similar thing as the packet counters on the ixgbe? My concern is that both solutions aside from that are not good: either we count less packets received than bytes received, or we count discarded packets as received packets. Is there any chance that a firmware update in the future could fix this? This sort of inconsistency, or inability to provide *good* stats, really sucks for a NIC. Thanks, Kyle