From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id AEDE2A04C3; Mon, 28 Sep 2020 16:01:43 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 176771D8D6; Mon, 28 Sep 2020 15:54:04 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 762101D53B; Mon, 28 Sep 2020 15:54:01 +0200 (CEST) IronPort-SDR: a25LkddH41y5u7nCXPFsGa+VVmheBHiOt6jd+tpOTkOwNnIb60t1IhEpy0iO6p4epgQKWlpPdm /vkPtAsg1IaQ== X-IronPort-AV: E=McAfee;i="6000,8403,9757"; a="159377301" X-IronPort-AV: E=Sophos;i="5.77,313,1596524400"; d="scan'208";a="159377301" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Sep 2020 06:53:59 -0700 IronPort-SDR: ZECh/CeOvTXU9jU9FzqxfbLlXh6f/Tm+D1BcM/nBf8wbbgmPkRPpfYyK/YNkkj7fp0DwtwSago pWbEz/ch7FiQ== X-IronPort-AV: E=Sophos;i="5.77,313,1596524400"; d="scan'208";a="488587729" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.193.117]) ([10.213.193.117]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Sep 2020 06:53:57 -0700 To: Thomas Monjalon Cc: "Min Hu (Connor)" , "techboard@dpdk.org" , stephen@networkplumber.org, bruce.richardson@intel.com, "jerinj@marvell.com" , Ray Kinsella , dev@dpdk.org References: <1598845317-55956-1-git-send-email-humin29@huawei.com> <1601176596-29900-2-git-send-email-humin29@huawei.com> <32785804.XpyAPG8jY8@thomas> From: Ferruh Yigit Message-ID: Date: Mon, 28 Sep 2020 14:53:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: <32785804.XpyAPG8jY8@thomas> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [dpdk-techboard] [PATCH V5 1/2] dpdk: resolve compiling errors for per-queue 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 9/28/2020 10:16 AM, Thomas Monjalon wrote: > 28/09/2020 10:59, Ferruh Yigit: >> On 9/27/2020 4:16 AM, Min Hu (Connor) wrote: >>> From: Huisong Li >>> >>> Currently, only statistics of rx/tx queues with queue_id less than >>> RTE_ETHDEV_QUEUE_STAT_CNTRS can be displayed. If there is a certain >>> application scenario that it needs to use 256 or more than 256 queues >>> and display all statistics of rx/tx queue. At this moment, we have to >>> change the macro to be equaled to the queue number. >>> >>> However, modifying the macro to be greater than 256 will trigger >>> many errors and warnings from test-pmd, PMD drivers and librte_ethdev >>> during compiling dpdk project. But it is possible and permitted that >>> rx/tx queue number is greater than 256 and all statistics of rx/tx >>> queue need to be displayed. In addition, the data type of rx/tx queue >>> number in rte_eth_dev_configure API is 'uint16_t'. So It is unreasonable >>> to use the 'uint8_t' type for variables that control which per-queue >>> statistics can be displayed. > > The explanation is too much complex and misleading. > You mean you cannot increase RTE_ETHDEV_QUEUE_STAT_CNTRS > above 256 because it is an 8-bit type? > > [...] >>> --- a/lib/librte_ethdev/rte_ethdev.h >>> +++ b/lib/librte_ethdev/rte_ethdev.h >>> int rte_eth_dev_set_tx_queue_stats_mapping(uint16_t port_id, >>> - uint16_t tx_queue_id, uint8_t stat_idx); >>> + uint16_t tx_queue_id, uint16_t stat_idx); > [...] >>> int rte_eth_dev_set_rx_queue_stats_mapping(uint16_t port_id, >>> uint16_t rx_queue_id, >>> - uint8_t stat_idx); >>> + uint16_t stat_idx); > [...] >> cc'ed tech-board, >> >> The patch breaks the ethdev ABI without a deprecation notice from previous >> release(s). >> >> It is mainly a fix to the port_id storage type, which we have updated from >> uint8_t to uint16_t in past but some seems remained for >> 'rte_eth_dev_set_tx_queue_stats_mapping()' & >> 'rte_eth_dev_set_rx_queue_stats_mapping()' APIs. > > No, it is not related to the port id, but the number of limited stats. > Right, it is not related to the port id, it is fixing the storage type for index used to map the queue stats. >> Since the ethdev library already heavily breaks the ABI this release, I am for >> getting this fix, instead of waiting the fix for one more year. > > If stats can be managed for more than 256 queues, I think it means > it is not limited. In this case, we probably don't need the API > *_queue_stats_mapping which was invented for a limitation of ixgbe. > > The problem is probably somewhere else (in testpmd), > that's why I am against this patch. > This patch is not to fix queue stats mapping, I agree there are problems related to it, already shared as comment to this set. But this patch is to fix the build errors when 'RTE_ETHDEV_QUEUE_STAT_CNTRS' needs to set more than 255. Where the build errors seems around the stats_mapping APIs.