From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 972791B4B7 for ; Fri, 15 Feb 2019 15:13:55 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Feb 2019 06:13:54 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,372,1544515200"; d="scan'208";a="134581233" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by orsmga002.jf.intel.com with ESMTP; 15 Feb 2019 06:13:54 -0800 Received: from fmsmsx154.amr.corp.intel.com (10.18.116.70) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 15 Feb 2019 06:13:54 -0800 Received: from fmsmsx117.amr.corp.intel.com ([169.254.3.143]) by FMSMSX154.amr.corp.intel.com ([169.254.6.137]) with mapi id 14.03.0415.000; Fri, 15 Feb 2019 06:13:53 -0800 From: "Wiles, Keith" To: "Richardson, Bruce" CC: David Marchand , Thomas Monjalon , dpdk-dev , "Lu, Wenzhuo" , "Wu, Jingjing" , "Iremonger, Bernard" , Maxime Coquelin , "Yigit, Ferruh" , "Andrew Rybchenko" Thread-Topic: [dpdk-dev] [PATCH 3/5] app/testpmd: add missing transmit errors stats Thread-Index: AQHUxTeSzvfOPCABzECDHV51MAbfF6XhbQmA Date: Fri, 15 Feb 2019 14:13:53 +0000 Message-ID: <4298C471-6BC5-413C-9F5A-7537828A498B@intel.com> References: <1550158972-21895-1-git-send-email-david.marchand@redhat.com> <4891070.GnHtSQePbW@xps> <20190215140526.GB790616@bricha3-MOBL.ger.corp.intel.com> In-Reply-To: <20190215140526.GB790616@bricha3-MOBL.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.251.136.143] Content-Type: text/plain; charset="us-ascii" Content-ID: <517B7C80C5A55748864B0B779E1DAE46@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 3/5] app/testpmd: add missing transmit errors stats X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 14:13:56 -0000 > On Feb 15, 2019, at 8:05 AM, Bruce Richardson wrote: >=20 > On Fri, Feb 15, 2019 at 10:33:47AM +0100, David Marchand wrote: >> On Fri, Feb 15, 2019 at 9:58 AM Thomas Monjalon >> <[1]thomas@monjalon.net> wrote: >>=20 >> 14/02/2019 19:51, David Marchand: >>> What is the purpose of oerrors ? >>>=20 >>> Since the drivers (via rte_eth_tx_burst return value) report the >> numbers of >>> packets successfully transmitted, the application can try to >> retransmit the >>> packets that did not make it and counts this. >>> If the driver counts such "missed" packets, then it does the job >> the >>> application will do anyway (wasting some cycles). >>> But what is more a problem is that the application does not know >> if the >>> packets in oerrors are its own retries or problems that the driver >> can not >>> detect (hw problems) but the hw can. >>>=20 >>> So the best option is that oerrors does not report the packets the >> driver >>> refuses (and I can see some drivers that do not comply to this) >> but only >>> "external" errors from the driver pov. >> I can see the benefit of having driver errors in the stats, >> so it is generically stored for later analysis or print. >> It could be managed at ethdev level instead of the application >> doing the computation. >> What about splitting the Tx errors in 2 fields? oerrors / ofull ? >> Who said it's awful? sorry Bruce for anticipating ;) >>=20 >> Summary, correct me if we are not aligned :-) >> - ofull (maybe ofifoerrors?) is actually a count of SW failed transmit= s >> - it would be handled in rte_eth_tx_burst() itself in a generic way >> - the drivers do not need to track such SW failed transmits >> - oerrors only counts packets HW failed transmits, dropped out of the >> driver tx_pkt_burst() knowledge >> - the application does not have to track SW failed transmits since the >> stats is in ethdev >> It sounds good to me, this means an ethdev abi breakage. >=20 > Hang on, why do we need ethdev to track this at all, given that it's > trivial for apps to track this themselves. Would we not be better just to > add this tracking into testpmd and leave ethdev and drivers alone? Perhap= s > I'm missing something? Adding the counters to ethdev stats is a good idea to me, the number of tx = full failures is a great counter as it can tell you a lot about performance= of the application. if the ofull counter is high then we have a lot of re-= xmit attempts which can point to the problem quicker IMO. Adding it to the = PMDs is the right place for this type of information as it is a very common= needed counter. >=20 Regards, Keith