From mboxrd@z Thu Jan 1 00:00:00 1970 From: "David Harton (dharton)" Subject: Re: [PATCH v2 1/2] ethdev: stop overriding rx_nombuf by rte_eth_stats_get Date: Wed, 23 Aug 2017 12:18:42 +0000 Message-ID: References: <20170823011937.37579-1-dharton@cisco.com> <20170823025555.19022-1-dharton@cisco.com> <1679481.0OI12NtS3X@xps> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" To: Thomas Monjalon Return-path: Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by dpdk.org (Postfix) with ESMTP id 1BEE17D3A for ; Wed, 23 Aug 2017 14:18:43 +0200 (CEST) In-Reply-To: <1679481.0OI12NtS3X@xps> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > -----Original Message----- > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Wednesday, August 23, 2017 3:52 AM > To: David Harton (dharton) > Cc: dev@dpdk.org > Subject: Re: [PATCH v2 1/2] ethdev: stop overriding rx_nombuf by > rte_eth_stats_get >=20 > 23/08/2017 04:55, David Harton: > > rte_eth_stats_get() unconditonally would set rx_nombuf even if the > > device was setting the value. A check has been added in > > rte_eth_stats_get() to leave the device value in-tact when non-zero. >=20 > If we get this counter from stats->rx_nombuf, why keeping > dev->data->rx_mbuf_alloc_failed ? > We could rework other PMDs to not use this global variable. > It is inconsistent to use it for some PMDs but not all. > And it seems not used outside of PMDs. Are you also asking to remove dev->data->rx_mbuf_alloc_failed as well since= we will have an ABI breakage anyway? On an somewhat related note, since we are introducing an ABI breakage how d= o you feel about re-adding the return code for the vlan_offload_set vector?= Some devices conditionally provide the ability to modify some offload and= the caller should know. Since I've got your attention thought I'd ask her= e before posting the patch. In fact, I believe all the API function calls should provide a return code = to help mitigate ABI breakages and also provide the ability to let the call= er distinguish between - no device, not supported and some other error. A = control plane often needs to understand these distinctions to properly orch= estrate the system and/or report real errors. This is more than I'm willin= g to take on myself but believe it's a principle I'd like to discuss (can s= tart separate thread if desired).