From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id B884EA04AF; Mon, 28 Sep 2020 11:16:46 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 90BC31B6C5; Mon, 28 Sep 2020 11:16:45 +0200 (CEST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by dpdk.org (Postfix) with ESMTP id 564B92AA0; Mon, 28 Sep 2020 11:16:43 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id EFC42C6B; Mon, 28 Sep 2020 05:16:40 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Mon, 28 Sep 2020 05:16:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= EIuDTJBWEu4r+L5Y0sYt0g+b2KJDy2yuTsie3pEQD90=; b=guvDakVCWlDnYnqa z9bLfzZ0DI/oHgO2hIrJUEl/x4oPBX8DOqbiHu5gR04YWQE9PmUCeabcswXxbnBT VxHRRNkF4qWjocLGAK5JMtxV6k041wUku7WcN7tmFjq3uXLcHxUTFpdmTPTPBqvb m7Tvof9SPyX1pvdOYMgv1yXRA9cWVCcfbtRifomhtFxsfqRRYToBEEwn1rtCK2cz Xl90vM9zQHh7vQEzYjeH66JGirRXSmIj9Mx2tPGNTP4nSK7QIDGCHRimFZrmc9CG U71Z7w3YVoYbdCilDgNhf8wlBF/cuYEq3ExUUEWPNxTe9Fml6NR4IDeX4q6yM3rX uhVNaw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=EIuDTJBWEu4r+L5Y0sYt0g+b2KJDy2yuTsie3pEQD 90=; b=srxzXt1L1o4MUA1FtcpKx9ohtkNZkf5W6aMGsXjNYN82RfA/Ltq8ucplZ ZdG1KYPDktZHSXS5kugxLSG4tsOQz96O7YbS7JrJz6u9AWKdmmj//eOkLJO3k9aa zSTx6Cs360OdxgC2BvJeLalBbMn18kOg+dtQ4OiDu/k3ok7L3nKluM75wdLP/Epx JFFS6ezqDKDY2OIX0W73Lwe4dlRMOBxYCsWDJ1Fmt0a/ZnuIemF36k9K64/UGEDU /8tfGul6ENDOM0JeEitL27Yu1dlvTj50mt9HzmFx9yst2kKXPAS0Aa7ZvVu8LAw+ cBWBF7eXIaXpiXIttX8+EVWVWHfAQ== X-ME-Sender: <xms:96lxX1dJJUuWJuHhSywpTfomlsRms0wQ9r8TctSz4A3TU1SV3LklNA> <xme:96lxXzOA7tRWxdJyFdLp9JPgXsOa05raHW_z_XyeDJS5DQSlKFTKID3MTQCYV7QE_ vssS6-Baot_70ykXA> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdeigdduhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: <xmx:96lxX-i_HlGy-kzeAzi11x2pPP0fGyb7VXoxEvApFSQKlVyXKvEDpA> <xmx:96lxX--RRYmrsfYfQYtO0MwXM0cyPNJrB_cmsc-QqGMdwp5fTIAuyg> <xmx:96lxXxuhU_rHP03fLw2fzXbAIi7DkeL3hQjkHRzZBhx2Gx6Y_LbQvw> <xmx:-KlxX_WPwvoSYlcZ1XRwXzkc5w_GTIxXjpLI7RLlubB62pL8v8keXQ> Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 950903280060; Mon, 28 Sep 2020 05:16:38 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: Ferruh Yigit <ferruh.yigit@intel.com> Cc: "Min Hu (Connor)" <humin29@huawei.com>, "techboard@dpdk.org" <techboard@dpdk.org>, stephen@networkplumber.org, bruce.richardson@intel.com, "jerinj@marvell.com" <jerinj@marvell.com>, Ray Kinsella <mdr@ashroe.eu>, dev@dpdk.org Date: Mon, 28 Sep 2020 11:16:37 +0200 Message-ID: <32785804.XpyAPG8jY8@thomas> In-Reply-To: <c39af420-5faa-7742-a0ed-9611b13c3bc3@intel.com> References: <1598845317-55956-1-git-send-email-humin29@huawei.com> <1601176596-29900-2-git-send-email-humin29@huawei.com> <c39af420-5faa-7742-a0ed-9611b13c3bc3@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> 28/09/2020 10:59, Ferruh Yigit: > On 9/27/2020 4:16 AM, Min Hu (Connor) wrote: > > From: Huisong Li <lihuisong@huawei.com> > > > > 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. > 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.