From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 1E8001B4A2 for ; Fri, 15 Feb 2019 15:05:31 +0100 (CET) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Feb 2019 06:05:31 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,372,1544515200"; d="scan'208";a="124735664" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.36]) by fmsmga008.fm.intel.com with SMTP; 15 Feb 2019 06:05:28 -0800 Received: by (sSMTP sendmail emulation); Fri, 15 Feb 2019 14:05:27 +0000 Date: Fri, 15 Feb 2019 14:05:26 +0000 From: Bruce Richardson To: David Marchand Cc: Thomas Monjalon , dev@dpdk.org, Wenzhuo Lu , Jingjing Wu , bernard.iremonger@intel.com, Maxime Coquelin , "Yigit, Ferruh" , Andrew Rybchenko Message-ID: <20190215140526.GB790616@bricha3-MOBL.ger.corp.intel.com> References: <1550158972-21895-1-git-send-email-david.marchand@redhat.com> <4891070.GnHtSQePbW@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.2 (2019-01-07) 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:05:32 -0000 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: > > 14/02/2019 19:51, David Marchand: > > What is the purpose of oerrors ? > > > > 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. > > > > 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 ;) > > Summary, correct me if we are not aligned :-) > - ofull (maybe ofifoerrors?) is actually a count of SW failed transmits > - 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. 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? Perhaps I'm missing something?