From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 6C65F2A07 for ; Mon, 7 Sep 2015 13:44:16 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP; 07 Sep 2015 04:44:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,484,1437462000"; d="scan'208";a="799985731" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by fmsmga002.fm.intel.com with ESMTP; 07 Sep 2015 04:44:14 -0700 Received: from irsmsx109.ger.corp.intel.com ([169.254.13.183]) by irsmsx105.ger.corp.intel.com ([169.254.7.51]) with mapi id 14.03.0224.002; Mon, 7 Sep 2015 12:44:13 +0100 From: "Tahhan, Maryam" To: Olivier MATZ , Andriy Berestovskyy Thread-Topic: ixgbe: account more Rx errors Issue Thread-Index: AQHQ5vWD8a2YwZRNdUGoHefwCprBbJ4sTN3AgAA6WQCAAq2K0IABe3UAgAA/ITA= Date: Mon, 7 Sep 2015 11:44:12 +0000 Message-ID: <1A27633A6DA49C4A92FCD5D4312DBF536A50C611@IRSMSX109.ger.corp.intel.com> References: <1A27633A6DA49C4A92FCD5D4312DBF536A508A73@IRSMSX109.ger.corp.intel.com> <1A27633A6DA49C4A92FCD5D4312DBF536A50A7FE@IRSMSX109.ger.corp.intel.com> <55ED4B22.8020708@6wind.com> In-Reply-To: <55ED4B22.8020708@6wind.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.181] 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: Mon, 07 Sep 2015 11:44:17 -0000 > From: Olivier MATZ [mailto:olivier.matz@6wind.com] > Sent: Monday, September 7, 2015 9:30 AM > To: Tahhan, Maryam; Andriy Berestovskyy > Cc: dev@dpdk.org > Subject: Re: ixgbe: account more Rx errors Issue >=20 > Hi, >=20 > On 09/06/2015 07:15 PM, Tahhan, Maryam wrote: > >> 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 > >> > >> Hi Maryam, > >> Please see below. > >> > >>> XEC counts the Number of receive IPv4, TCP, UDP or SCTP XSUM errors > >> > >> Please note than UDP checksum is optional for IPv4, but UDP packets > >> with zero checksum hit XEC. > >> > > > > 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 datashee= t. > > > >>> And general crc errors counts Counts the number of receive packets > >>> with > >> CRC errors. > >> > >> Let me explain you with an example. > >> > >> DPDK 2.0 behavior: > >> host A sends 10M IPv4 UDP packets (no checksum) to host B host B > >> stats: 9M ipackets + 1M ierrors (missed) =3D 10M > >> > >> DPDK 2.1 behavior: > >> host A sends 10M IPv4 UDP packets (no checksum) to host B host B > >> stats: 9M ipackets + 11M in ierrors (1M missed + 10M XEC) =3D 20M? > > > > Because it's hitting the 2 error registers. If you had packets with mul= tiple > 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 below. > What I'm saying is the number of errors being > the number of received > packets will be seen if you hit multiple error registers on the NIC. > > > >> > >>> 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 have multiple errors anyway. > >> > >> 4. ierrors should reflect NIC drops only. > > > > I may have misinterpreted this, but ierrors in rte_ethdev.h ierrors is = defined > 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 dropped. > > > >> 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 > > necessarily be doing), removing it could mean missing other valid > > L3/L4 checksum errors... Let me experiment some more with L3/L4 > > checksum errors and crcerrs to see if we can cook the stats around > > this register in particular. I would hate to remove it and miss > > genuine errors >=20 > For me, the definition that looks the most straightforward is: >=20 > ipackets =3D packets successfully received by hardware imissed =3D packet= s > dropped by hardware because the software does > not poll fast enough (=3D queue full) > ierrors =3D packets dropped by hardware (malformed packets, ...) >=20 > These 3 stats never count twice the same packet. >=20 > If we want more statistics, they could go in xstats. For instance, a coun= ter for > invalid checksum. The definition of these stats would be pmd-specific. >=20 > I agree we should clarify and have a consensus on the definitions before = going > further. >=20 >=20 > Regards, > Olivier Hi Olivier I think it's important to distinguish between errors and drops and provide = a statistics API that exposes both. This way people have access to as much = information as possible when things do go wrong and nothing is missed in te= rms of errors. My suggestion for the high level registers would be: ipackets =3D Total number of packets successfully received by hardware imissed =3D Total number of packets dropped by hardware because the softwa= re does not poll fast enough (=3D queue full) idrops =3D Total number of packets dropped by hardware (malformed packets, = ...) Where the # of drops can ONLY be <=3D the packets received (without o= verlap between registers). ierrors =3D Total number of erroneous received packets. Where the # of erro= rs can be >=3D the packets received (without overlap between registers), th= is is because there may be multiple errors associated with a packet. This way people can see how many packets were dropped and why at a high lev= el as well as through the extended stats API rather than using one API or t= he other. What do you think? Best Regards Maryam >=20 >=20 >=20 > > > >> > >> Please note that we still can access the XEC using > >> rte_eth_xstats_get() > >> > >> > >> Regards, > >> Andriy