From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id D11388E93 for ; Sun, 6 Sep 2015 19:15:18 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP; 06 Sep 2015 10:15:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,480,1437462000"; d="scan'208";a="556499429" Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by FMSMGA003.fm.intel.com with ESMTP; 06 Sep 2015 10:15:16 -0700 Received: from irsmsx109.ger.corp.intel.com ([169.254.13.183]) by IRSMSX153.ger.corp.intel.com ([169.254.9.13]) with mapi id 14.03.0224.002; Sun, 6 Sep 2015 18:15:16 +0100 From: "Tahhan, Maryam" To: Andriy Berestovskyy Thread-Topic: ixgbe: account more Rx errors Issue Thread-Index: AQHQ5vWD8a2YwZRNdUGoHefwCprBbJ4sTN3AgAA6WQCAAq2K0A== Date: Sun, 6 Sep 2015 17:15:15 +0000 Message-ID: <1A27633A6DA49C4A92FCD5D4312DBF536A50A7FE@IRSMSX109.ger.corp.intel.com> References: <1A27633A6DA49C4A92FCD5D4312DBF536A508A73@IRSMSX109.ger.corp.intel.com> In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] ixgbe: account more Rx errors Issue 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: Sun, 06 Sep 2015 17:15:19 -0000 > From: Andriy Berestovskyy [mailto:aber@semihalf.com] > Sent: Friday, September 4, 2015 5:59 PM > To: Tahhan, Maryam > Cc: dev@dpdk.org; Olivier MATZ > Subject: Re: ixgbe: account more Rx errors Issue >=20 > Hi Maryam, > Please see below. >=20 > > XEC counts the Number of receive IPv4, TCP, UDP or SCTP XSUM errors >=20 > Please note than UDP checksum is optional for IPv4, but UDP packets with > zero checksum hit XEC. >=20 I understand, but this is what the hardware register is picking up and what= I included previously is the definitions of the registers from the datashe= et. > > And general crc errors counts Counts the number of receive packets with > CRC errors. >=20 > Let me explain you with an example. >=20 > DPDK 2.0 behavior: > host A sends 10M IPv4 UDP packets (no checksum) to host B host B stats: 9= M > ipackets + 1M ierrors (missed) =3D 10M >=20 > DPDK 2.1 behavior: > host A sends 10M IPv4 UDP packets (no checksum) to host B host B stats: 9= M > ipackets + 11M in ierrors (1M missed + 10M XEC) =3D 20M? Because it's hitting the 2 error registers. If you had packets with multipl= e errors that are added up as part of ierrors you'll still be getting more = than 10M errors which is why I asked for feedback on the 3 suggestions belo= w. What I'm saying is the number of errors being > the number of received p= ackets will be seen if you hit multiple error registers on the NIC. >=20 > > So our options are we can: > > 1. Add only one of these into the error stats. > > 2. We can introduce some cooking of stats in this scenario, so only add > either or if they are equal or one is higher than the other. > > 3. Add them all which means you can have more errors than the number of > received packets, but TBH this is going to be the case if your packets ha= ve > multiple errors anyway. >=20 > 4. ierrors should reflect NIC drops only. I may have misinterpreted this, but ierrors in rte_ethdev.h ierrors is defi= ned as the Total number of erroneous received packets. Maybe we need a clear definition or a separate drop counter as I see uint64= _t q_errors defined as: Total number of queue packets received that are dro= pped. > XEC does not count drops, so IMO it should be removed from ierrors. While it's picking up the 0 checksum as an error (which it shouldn't necess= arily be doing), removing it could mean missing other valid L3/L4 checksum = errors... Let me experiment some more with L3/L4 checksum errors and crcerr= s to see if we can cook the stats around this register in particular. I wou= ld hate to remove it and miss genuine errors=20 >=20 > Please note that we still can access the XEC using rte_eth_xstats_get() >=20 >=20 > Regards, > Andriy