From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by dpdk.org (Postfix) with ESMTP id 0C5E27D53 for ; Wed, 23 Aug 2017 23:27:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2652; q=dns/txt; s=iport; t=1503523658; x=1504733258; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KcZlxlalz90imi5E6EF/pEeIQtzbQWpaXruHeh8drSY=; b=T4ohKYMFXrdToAX591x3LubaThQgDdR8cn61WT8tx+CB8F8s7tQjnKiW rnoJDQvv4WiTJPFfhqNn963olUDL8RlLZj7C5eV5acju1GGpZtSQXMbR+ z+jBX9HrKI21/gNxzUbUiTDTn0UWaE5XN/K2mdGeGIkKv1Jwsso/12MyM U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C1AAAd8p1Z/4ENJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1qBeQeODZAWgXCRQIRkghKFRwKERj8YAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQECAScTPwwEAgEIEQQBAR8JBzIUCQgCBA4FCIohCLA+OotgAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHYMqggKBTIUKimcFhzaZIgKOfoU7km1IlWUBHziBCncVhWA?= =?us-ascii?q?cgWd2iXKBDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,417,1498521600"; d="scan'208";a="276145684" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Aug 2017 21:27:36 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v7NLRarL009344 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 23 Aug 2017 21:27:36 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 23 Aug 2017 16:27:35 -0500 Received: from xch-rcd-016.cisco.com ([173.37.102.26]) by XCH-RCD-016.cisco.com ([173.37.102.26]) with mapi id 15.00.1210.000; Wed, 23 Aug 2017 16:27:35 -0500 From: "David Harton (dharton)" To: Thomas Monjalon CC: "dev@dpdk.org" Thread-Topic: [PATCH v2 1/2] ethdev: stop overriding rx_nombuf by rte_eth_stats_get Thread-Index: AQHTG7tY3pFJFf86Tka5akmSQJp7mqKR5a+A///zVxCAAGmMAIAAMZ8A Date: Wed, 23 Aug 2017 21:27:35 +0000 Message-ID: <840715e081a542788c217ef639dac766@XCH-RCD-016.cisco.com> References: <20170823011937.37579-1-dharton@cisco.com> <1679481.0OI12NtS3X@xps> <3459676.trPQTB1ucG@xps> In-Reply-To: <3459676.trPQTB1ucG@xps> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.213.192] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 21:27:38 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Wednesday, August 23, 2017 9:24 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 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? >=20 > Not asking, just giving my thought :) I did some more digging. For this count it looks like some devices: - have their own internal version - have a count shared with the pf - rely on this field to maintain the count - don't count this failure at all :( With that said I'd like to keep with the requested changes. Thoughts? Dave >=20 > > 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 though= t > I'd ask here before posting the patch. >=20 > Seems reasonnable >=20 > > > > 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). > > >=20 > Yes you're right