From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by dpdk.org (Postfix) with ESMTP id DE06A2BF5 for ; Wed, 26 Apr 2017 00:49:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3209; q=dns/txt; s=iport; t=1493160576; x=1494370176; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=qcn4vB4tb4ZuouaiL7tFtm7h1/ckTzKnxrbEAVrrr70=; b=glQnZu3gD4ciy4MjqIZGXfLOGyM7CMe4/Em4zB42lFZwHGQHbK6B1QkT KIP8z1WAvRrMCwvuy6e3z8X3RD6HJzJ+p1VyMBsTNH8hZwsZT79htDE3U rDtqFW1GvoVfvIQTOBREMZVkqw9TNuCtGTU9Spx3k89Em7hHBIi6WG4M0 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C3AQAx0f9Y/5hdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1SBbYNnihWRTiFwlHWCD4YkAoQVPxgBAgEBAQEBAQFrKIUVAQE?= =?us-ascii?q?BAQMjFU0ECxEEAQEBAgIREgMCAkYJCBMGAgEBihirCYImiysBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBASGBC4VIgV0rC4IvNIUWgkeCXwEEkAuNNpMGggCFM4NChmKUGR84gQZ?= =?us-ascii?q?DIBVEhGkcGYFmJDUBiTUBAQE?= X-IronPort-AV: E=Sophos;i="5.37,251,1488844800"; d="scan'208";a="417681648" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Apr 2017 22:49:35 +0000 Received: from [10.116.86.169] (rtp-rmelton-8818.cisco.com [10.116.86.169]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v3PMnZcj027142 for ; Tue, 25 Apr 2017 22:49:35 GMT To: dev@dpdk.org References: <1491928644-10383-2-git-send-email-michalx.k.jastrzebski@intel.com> <2191902.oqd7qsnxNQ@xps> <20170424143211.3e7db919@platinum> <23329330.ZWGR8gsYE6@xps> From: Roger B Melton Message-ID: Date: Tue, 25 Apr 2017 18:49:34 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: [dpdk-dev] [PATCH v6 0/5] Extended xstats API in ethdev library to allow grouping of stats 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: Tue, 25 Apr 2017 22:49:37 -0000 On 4/24/17 11:49 AM, Mcnamara, John wrote: >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon >> Sent: Monday, April 24, 2017 1:41 PM >> To: Kozak, KubaX >> Cc: dev@dpdk.org; Olivier Matz ; Van Haaren, Harry >> ; Jain, Deepak K ; >> Piasecki, JacekX >> Subject: Re: [dpdk-dev] [PATCH v6 0/5] Extended xstats API in ethdev >> library to allow grouping of stats >> >> 24/04/2017 14:32, Olivier Matz: >>> Hi, >>> >> ... >>> So, I wonder if it wouldn't be more simple to keep the old API intact >>> (it would avoid unannounced breakage). The new feature can be >>> implemented in an additional API: >>> >>> rte_eth_xstats_get_by_id(uint8_t port_id, const uint64_t *ids, >>> uint64_t *values, unsigned int size) >>> rte_eth_xstats_get_names_by_id(uint8_t port_id, const uint64_t *ids, >>> struct rte_eth_xstat_name *xstats_names, unsigned int size) >>> >>> Or: >>> >>> rte_eth_xstats_get_by_id(uint8_t port_id, const uint64_t *ids, >>> struct rte_eth_xstat *values, unsigned int size) >>> rte_eth_xstats_get_names_by_id(uint8_t port_id, const uint64_t *ids, >>> struct rte_eth_xstat_name *xstats_names, unsigned int size) >>> >>> (which would allow to deprecate the old API, but I'm not sure >>> we need to) >>> >>> >>> Can we fix that for 17.05? >> ... >> >> Back to the issues, please try to fix it quickly or we should revert it >> for 17.05-rc3. > Hi, > > We'll submit a patch to change the APIs for rte_eth_xstats_get() and > rte_eth_xstats_get_names() back to their previous signature, without > symbol versions, and add the APIs suggested by Olivier. > > We'll work on that as soon as possible. > > John > . > Hi folks, I adapted our application to the API changes presented in 17.05-rc2 and encountered problem that I don't think was pointed out in Olivier's list of issues. In our application we call rte_eth_stats_get() with NULL pointers to determine the number of xstats. We use the returned count to pre-allocate buffers for the name strings and xstats values and then invoke rte_eth_xstats_get_names() and rte_eth_xstats_get() with pointers to appropriately sized buffers and the number of entries available in those buffers. Things appeared to work fine until I requested stats for a net_ixgbe_vf port. In that case the initial call to rte_eth_xstats_get() did not account for the xstats extensions from the ixgbevf PMD. Long story short, my buffers were undersized and bad things happened. John, If you intend to restore the previous API signature but retain the -rc2 internal implementation, may I suggest that both APIs use the same internal function to determine stats count. Otherwise the potential for disagreement between the APIs will remain. Also while on this topic, IMO the above demonstrates that we really need an API to query the xstats count rather than relying on rte_eth_xstats_get() or rte_eth_xstats_get_names() with 0'd out arguments. Regards, Roger