From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH 3/5] app/testpmd: add missing transmit errors stats Date: Fri, 15 Feb 2019 09:57:58 +0100 Message-ID: <4891070.GnHtSQePbW@xps> References: <1550158972-21895-1-git-send-email-david.marchand@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org, Bruce Richardson , Wenzhuo Lu , Jingjing Wu , bernard.iremonger@intel.com, Maxime Coquelin , ferruh.yigit@intel.com, arybchenko@solarflare.com To: David Marchand Return-path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 2CE9D1B47B for ; Fri, 15 Feb 2019 09:58:01 +0100 (CET) In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 ;)