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 874CBA04C3; Mon, 28 Sep 2020 17:44:11 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1673F1DA03; Mon, 28 Sep 2020 17:44:09 +0200 (CEST) Received: from mail-pg1-f195.google.com (mail-pg1-f195.google.com [209.85.215.195]) by dpdk.org (Postfix) with ESMTP id DB7141D9FD for ; Mon, 28 Sep 2020 17:44:07 +0200 (CEST) Received: by mail-pg1-f195.google.com with SMTP id s31so1198295pga.7 for ; Mon, 28 Sep 2020 08:44:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=poldlztNE5HSw5oQwYchcVEzGYLPv13HC67cG0YaQ9M=; b=Q1krgEIHHtzfqPz0aCJdU56+9zlEgUp1yYQkQKmrWm9Viwggu00XVA2hztO/CNlKbu fWh2o+lVPw2X3TNS4EqfjCYcS6otyu+rz/FcbXLk9I9I5/Os+cbsli4KqArU+onfbdPk fWp9OgBP1+fSIqeDVzodbTxjh+kRxZ/ihWs8IHtoNi7e55Fyvq0vf4kl9+vjbdhCy9m1 OnvIq6yiFOayfzW+1NNeJDAiFLNZw6LBazvas6WdZ7HCFeLF02Ub7jqi8XRao6dOwOUB cNl2fucp/Ds37qkxuEowK6KUqROUnMEF0z3SJVN0Ma/oP3CiRP5YTj68zO0cI9tKQfOI +fJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=poldlztNE5HSw5oQwYchcVEzGYLPv13HC67cG0YaQ9M=; b=hf/Xwpz8jA4QDEXDPnL0gNGSlKZ+zh4Y0oM9Wc0FR6yi5IwzTbGSX5qjbFz0g2wpEO ylg/VZkqES3OQsdoR67kid3dOtBCULTN1f/eI+jewnuPUL887yhocwdtxJAWRifEg+1E ddPL6y2vLEdSHRXSKljSrepb3q7lOs57/7SnFvPgwZSiHGrf9ZJsTJ2witb8ZPQs0ckf NDqu3WXJwPv0oDF+Y/XyjYYenlpUVR9k2JYBii7l6IUAEna+dfC1p4FFJl7cjGZXaKnF eeuwo6OGF0zWtqVUv0TNYWDhh2J8dKppm1Cu43nA5KIm/LEhE08j2zhUiEAiLyYTQzno Eccw== X-Gm-Message-State: AOAM531dnBgp0E4K8AVz6SW5GWFRHaoaFfcLKRoDyyp3iClC7tB2muH5 pUhM2hV3oAABWoW8QiMrabVzKA== X-Google-Smtp-Source: ABdhPJxDJ0fXJ6h5+0Xu7cs5hB46MstMpEMwVebwpLgBH/CiASONqAfsv3y2t2mq8tFHFTtDu5tJbg== X-Received: by 2002:a17:902:c083:b029:d2:562f:d0a5 with SMTP id j3-20020a170902c083b02900d2562fd0a5mr126238pld.33.1601307845988; Mon, 28 Sep 2020 08:44:05 -0700 (PDT) Received: from hermes.local (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id t12sm2073047pfh.73.2020.09.28.08.44.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Sep 2020 08:44:05 -0700 (PDT) Date: Mon, 28 Sep 2020 08:43:57 -0700 From: Stephen Hemminger To: Thomas Monjalon Cc: Ferruh Yigit , "Min Hu (Connor)" , "techboard@dpdk.org" , bruce.richardson@intel.com, "jerinj@marvell.com" , Ray Kinsella , dev@dpdk.org Message-ID: <20200928084357.3dfab7ab@hermes.local> In-Reply-To: <9656261.dg2788STim@thomas> References: <1598845317-55956-1-git-send-email-humin29@huawei.com> <32785804.XpyAPG8jY8@thomas> <9656261.dg2788STim@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Mon, 28 Sep 2020 17:24:26 +0200 Thomas Monjalon wrote: > 28/09/2020 15:53, Ferruh Yigit: > > 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. > > It is not said this API is supposed to manage more than 256 queues mapping. > In general we should not need this API. > I think it is solving the wrong problem. The original API is a band aid for the limited number of statistics counters in the Intel IXGBE hardware. It crept into to the DPDK as an API. I would rather have per-queue statistics and make ixgbe say "not supported"