From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 09CC37D53 for ; Wed, 23 Aug 2017 15:24:13 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6DDD320CE9; Wed, 23 Aug 2017 09:24:13 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 23 Aug 2017 09:24:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=cLFwN+CDoV3azCL TeUQY62Gbj2AHREQxN+UZMOa64lc=; b=apZkUD2PBS5xWuLJf8fDVu/RK8tMcD9 TElJ+sLh4by8nHQVHgi6a4lfUOz/TcsOew97Mi3qXpOg7NKlyh46xLEl4EsBahL5 i7gnKdrTJtoUdhG6yOs55ti4OvIwfrLhNLP0eJgGg146MxeDlIrOygP7SYu+lgfs K5K18y9ffe+w= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=cLFwN+CDoV3azCLTeUQY62Gbj2AHREQxN+UZMOa64lc=; b=JdAb2b3k VSrp2Dj56BwfF7Yt57BwxdB5khf/hDJPuH9VA5ketZgEwupbHYz25dK3OoG2rYrl /WaLaRltypBZzfIe5RDtzG9JqGlWnORibW6wnAV7zJUSmcx6TzfTSuvT4Cmzi5QI O3Z3SBNB8gmTc3G0vI4hxHBoq4NzRX5ypCMj81D0ODhxDsba/nRGR/o6d2xvZBfQ oyt5ut3GhftNZBNeVuS8yZJdPrSaJUYy9GrXTwr1bEeWWs7ICazAi3NXsSszO4RV am82YcbyqAJy5D21rUu57uVIN1tyxJdUrYaxbsQEkRhTuITcOPx4xvKLeOT2g5Uu BwlzVR2dYrYkiQ== X-ME-Sender: X-Sasl-enc: PuTBtf5ipliPxwivVfcrIIUG8Tz7TufxbH/5ezXSpcK3 1503494653 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 2A5F724871; Wed, 23 Aug 2017 09:24:13 -0400 (EDT) From: Thomas Monjalon To: "David Harton (dharton)" Cc: dev@dpdk.org Date: Wed, 23 Aug 2017 15:24:12 +0200 Message-ID: <3459676.trPQTB1ucG@xps> In-Reply-To: References: <20170823011937.37579-1-dharton@cisco.com> <1679481.0OI12NtS3X@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 1/2] ethdev: stop overriding rx_nombuf by rte_eth_stats_get 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: Wed, 23 Aug 2017 13:24:14 -0000 23/08/2017 14:18, David Harton (dharton): > > > -----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 > > > > 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. > > > > 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? Not asking, just giving my thought :) > On an somewhat related note, since we are introducing an ABI breakage how do 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 here before posting the patch. Seems reasonnable > > 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 caller distinguish between - no device, not supported and some other error. A control plane often needs to understand these distinctions to properly orchestrate the system and/or report real errors. This is more than I'm willing to take on myself but believe it's a principle I'd like to discuss (can start separate thread if desired). > Yes you're right