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 EB595A04C3; Mon, 28 Sep 2020 17:35:15 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 38E781C18E; Mon, 28 Sep 2020 17:35:13 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id 17D441C117; Mon, 28 Sep 2020 17:35:11 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id ACE585C018A; Mon, 28 Sep 2020 11:35:09 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Mon, 28 Sep 2020 11:35:09 -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= 9+X7rscK2fnu+MFrS7I+T5SD/QB+h3B+wmA1UsLIAEQ=; b=J1uUcfjDRpTduc3T XtUiGs6zZ6rg4haoJ0B44zSaN8PXlhEnpTKmdlCPJ5txWWN/dOt8tvwYMJN2DOEL 15dELGDfI0cY2mCjy2GYQr/ErySzdLSug3Fnnpa9oEdiacYyDAKpwWuNVm28AWGh KhJLAcEACZdcjaJ9K/4W2Y0/GvdFKKLpyvy0aaMvwfiUaSPWvdqOlql6kRwIlyBD E8yDgsrBXnpOLLTtmSOYEe6QVOCTmm2f34sgQCZ3IOr3jaNSilwMMoXUJJ8PVcXn ay64IW/qGdArGz57XaL89Y0Irw1ZbmFizf8HqPry9LSsU+fB2g04nszwNpVmW17U m78yCw== 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=9+X7rscK2fnu+MFrS7I+T5SD/QB+h3B+wmA1UsLIA EQ=; b=DlxyzEUh4BGjJky5MIdVBWhO5r23/B7bF4R/5pOmtK63xlJ8mxBZwuZbE e06v8DPrCH2S8tekoX7mTeczAs5VatfnPIZU/P2I6AJvn/f4ZNow9Z9eWPBE+TlL tM9ogOdo55Je1Qv5ggiTfmyftPkp/O/7Uw1VmZWaUtMPlXxhGdTB+dY2AUgmOWwZ lZ7h3eX0qhJGat2hwm04rIm/9KGX4LlaK4veKaKBhlUCeYEuVtABHWdLnVmr7Wd2 YRsbTGqS+JqP2JvmCpycjzDHwOF5S2A2efQSt5FBd5r5/bpwCoCTXAQT1jIUD0A+ VLtAT3Rdj5PoIJIVcNYQEzVWDrFZA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdeigdeikecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpeekteehtdeivefhieegjeelgedufeejheekkeetueevieeuvdevuedt jeevheevteenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id B8C403280069; Mon, 28 Sep 2020 11:35:07 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit , "Min Hu (Connor)" Cc: "techboard@dpdk.org" , stephen@networkplumber.org, bruce.richardson@intel.com, "jerinj@marvell.com" , Ray Kinsella , dev@dpdk.org Date: Mon, 28 Sep 2020 17:35:06 +0200 Message-ID: <2912407.toSi1mmUbU@thomas> In-Reply-To: <1f51b8e9-de81-9a11-788e-2d16ea3822f3@huawei.com> References: <1598845317-55956-1-git-send-email-humin29@huawei.com> <32785804.XpyAPG8jY8@thomas> <1f51b8e9-de81-9a11-788e-2d16ea3822f3@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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" 28/09/2020 15:47, Min Hu (Connor): >=20 > =E5=9C=A8 2020/9/28 17:16, Thomas Monjalon =E5=86=99=E9=81=93: > > 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 unreasona= ble > >>> to use the 'uint8_t' type for variables that control which per-queue > >>> statistics can be displayed. > >=20 > > 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? > >=20 > Hi, Thomas, > you may misunderstand it. > The goal of this patch is that resolving some errors or warnings when=20 > compiling code with RTE_ETHDEV_QUEUE_STAT_CNTRS > 256. The reson is some > vlaue(uint8_t) will never catch over RTE_ETHDEV_QUEUE_STAT_CNTRS, as > uint8_t ranges from 0-255. e.g., > static void > nic_stats_display(uint16_t port_id) > { > uint8_t i; > for (i =3D 0; i < RTE_ETHDEV_QUEUE_STAT_CNTRS; i++) { > ... > } > ... > } What you are describing is not a problem, it is the API: queue stats mapping is to map few queues (less than 256). > RTE_ETHDEV_QUEUE_STAT_CNTRS can be increased to more than 256, which is=20 > reasonable in principle. Because the number of queue statistics is > controlled by it. And mapping queue to queue statistics counter is also > controlled by it. No, queue statistics ID should be the queue ID (1:1 mapping), except for rare limited HW. > So these "*_queue_stats_mapping" API also trigger=20 > errors or warning. >=20 > > [...] > >>> --- 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 prev= ious > >> 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. > >=20 > > No, it is not related to the port id, but the number of limited stats. > >=20 > >> 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. > >=20 > > 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. > >=20 > First, my modification for "stat_idx" data type is resonable and it > does not cause some problems. Why do you think it is reasonnable? What is the use case? > Both queue id and stat_idx have same > type, which is also reasoable in usage. > Then, "*_queue_stats_mapping" these API is not only invented for ixgbe. > other net drivers also implements the API, like enic, igc, octeontx2 et= c. I don't think enic implements it, and I don't know what is the intent in igc and octeontx2 (maybe just a copy/paste). > > The problem is probably somewhere else (in testpmd), > > that's why I am against this patch. We should start from the beginning: why do you increase this value? Or we can go directly to the real issue: testpmd shows queues statistics only if a mapping is defined. This testpmd behaviour is absolutely wrong and should be fixed.