From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by dpdk.org (Postfix) with ESMTP id B3AD2475D for ; Fri, 29 Apr 2016 14:52:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2988; q=dns/txt; s=iport; t=1461934355; x=1463143955; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=R22p9jRIv1LCf9eQc7U11GhFFFAqbhFhHwudAAljkvg=; b=EpdTW7n+A6chFZZUtBqnGMw+85boWAZTzvCICo93ZoCN7aNMl//oIIIx KUZRBc/iUXlL7VewLi/d/a21boBDJowsJtneEJZcAYwoKmXaXiGD7uTcq iQKcdR3IFiOpRvG49XTkwFDoAQEDJb0Bj2y9MU2Hoc9FPGFee0tS+ntYo 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMAgDaVyNX/5BdJa1dgziBUAa3XIIPA?= =?us-ascii?q?Q2BdoYPAoEwOBQBAQEBAQEBZSeEQQEBAQMBOksEAgEIEQQBAR8JBzIUCQgCBAE?= =?us-ascii?q?SCIgaCMQVAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYhhEyKEwWNVoo9AYhyhR2PG?= =?us-ascii?q?I8vAR4BAUKDa2yIAn8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,551,1454976000"; d="scan'208";a="97000365" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Apr 2016 12:52:34 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u3TCqYuh024393 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Apr 2016 12:52:34 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 29 Apr 2016 07:52:34 -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.1104.009; Fri, 29 Apr 2016 07:52:33 -0500 From: "David Harton (dharton)" To: Remy Horton , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [RFC PATCH v1 0/3] Remove string operations from xstats Thread-Index: AQHRlyVTq5+EWbgW3kKb6tsWJ2kqsZ+g815w Date: Fri, 29 Apr 2016 12:52:33 +0000 Message-ID: <5f173a44b92c421fb4ee90f085aa4842@XCH-RCD-016.cisco.com> References: <1460731462-21229-1-git-send-email-remy.horton@intel.com> In-Reply-To: <1460731462-21229-1-git-send-email-remy.horton@intel.com> 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.212.42] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC PATCH v1 0/3] Remove string operations from xstats X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 12:52:36 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Remy Horton > Sent: Friday, April 15, 2016 10:44 AM > To: dev@dpdk.org > Subject: [dpdk-dev] [RFC PATCH v1 0/3] Remove string operations from > xstats >=20 > The current extended ethernet statistics fetching involve doing several > string operations, which causes performance issues if there are lots of > statistics and/or network interfaces. This RFC patchset changes the API > for xstats to use integer identifiers instead of strings and implements > this new API for the ixgbe driver. Others drivers to follow. >=20 > -- >=20 > Since this will involve API & ABI breakage as previously advertised, > there are several design assumptions that need consideration: >=20 > *) id-name & id-value pairs for both lookup and query > Permits out-of-order and non-contigious returning of names/ids/values, > even though expected implmentations would in practice return items in > sorted order by id. Is this sufficent/desirable future proofing? Idea > is to allow possibility of drivers returning partial statistics. I think the key is that the order of the stats must always be honored=20 and if that's the case then an id isn't necessary. However, if others=20 want an id certainly doesn't hurt. I don't see drivers autonomously providing a subset of stats and users=20 can filter out stats they don't want to their presentation layers. >=20 > *) Bulk name-id mapping lookup only > At the moment individual lookup is not supported, as this would impose > extra overheads on drivers. The assumption is that any end user would > fetch all this data once on startup and then cache the mappings. Agreed. Similarly there is no need to return a partial list of stats=20 as the presentation layers can filter. >=20 > *) Replacement or additional API > This patch replaces the current xstats API, but there is no inherant > reason beyond maintainability why this funtionality could not be in > addition rather than a replacement. What is consensus on this? I suggest 3 new functions are added: - get number of xstats - get xstats names - get xstats values This facilitates: - parallel development within the release without breaking current usage - possibility of removing rte_eth_xstats_get() in following release Thanks for moving this forward, Dave >=20 > Comments welcome. >=20 > Remy Horton (3): > rte: change xstats to use integer keys > drivers/net/ixgbe: change xstats to use integer keys > examples/ethtool: add xstats display command >=20 > drivers/net/ixgbe/ixgbe_ethdev.c | 87 > +++++++++++++++++++++++++++++++---- > examples/ethtool/ethtool-app/ethapp.c | 57 +++++++++++++++++++++++ > lib/librte_ether/rte_ethdev.c | 87 > +++++++++++++++++++++++++++++++---- > lib/librte_ether/rte_ethdev.h | 38 +++++++++++++++ > 4 files changed, 252 insertions(+), 17 deletions(-) >=20 > -- > 2.5.5