From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 6010929C7 for ; Thu, 3 Nov 2016 03:00:42 +0100 (CET) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga103.jf.intel.com with ESMTP; 02 Nov 2016 19:00:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,436,1473145200"; d="scan'208";a="27151763" Received: from rhorton-mobl.ger.corp.intel.com (HELO [10.239.204.17]) ([10.239.204.17]) by orsmga004.jf.intel.com with ESMTP; 02 Nov 2016 19:00:38 -0700 To: "Mcnamara, John" , "Dai, Wei" , Thomas Monjalon , "Ananyev, Konstantin" , "Wu, Jingjing" , "Zhang, Helin" , "Curran, Greg" , "Van Haaren, Harry" References: <1472206104-22035-1-git-send-email-wei.dai@intel.com> <2544827.v0ahXV4zxG@xps13> <49759EB36A64CF4892C1AFEC9231E8D63A2EB13C@PGSMSX106.gar.corp.intel.com> From: Remy Horton Organization: Intel Shannon Limited Message-ID: Date: Thu, 3 Nov 2016 10:00:37 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH] ethdev: fix statistics description 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: Thu, 03 Nov 2016 02:00:42 -0000 On 02/11/2016 17:07, Mcnamara, John wrote: [..] > Perhaps we could an API that returns a struct, or otherwise, that > indicated what stats are returned by a PMD. An application that > required stats could call it once to establish what stats were > available. It would have to be done in some way that wouldn't break > ABI every time a new stat was added. > > Harry, Remy, how would this fit in with the existing stats scheme or > the new metrics library. At the moment xstats (rte_eth_xstats_get()) pulls stuff out of rte_eth_stats and reports them unconditionally alongside all the driver-specific xstats. This could change so that it only reports the (legacy) stats the PMDs actually fills in. Personally in the longer term I think xstats should get all the info it requires directly rather than relying on the legacy stats for some of its info, but that would involve pushing a lot of common code into the PMDs.. ..Remy