From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9F2EC41D9E; Tue, 28 Feb 2023 17:14:51 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 41BE540EE6; Tue, 28 Feb 2023 17:14:51 +0100 (CET) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2040.outbound.protection.outlook.com [40.107.223.40]) by mails.dpdk.org (Postfix) with ESMTP id 24F9B4021F for ; Tue, 28 Feb 2023 17:14:49 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aLBIyDOTeLBkDlzmhMQiLeiFeYSzNNvvuiEbFTmnNCJrFgWOnQ/KTwu3RlEDC7XewFQ6EapU3o7k/2qNpMVKg/L/QK1lIuMjM0+Y3c5SltNcQ/UkJQIVJtM2e4HL9nNvthemVUuoCvOUXogMiu/84/URfdksLXRXqaZbirBmunwrcUjoPUxB/xeHVWJvZB/yEr7VbXc9KW5uCyGb1TRJhN+/lbDorM2YCw5t2jFFvEO46eGVAkWxxhVYFhmB03w0N4Ag84NrlZsD0YQp55jOmTRz4rHkxEz27ck4ERTz5TUZMHcpSW4a3Va4+xvolrS2EJccVbdBzLjouugrDBKaeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GkcPHbpVbcg8+l6wDoBtpgB5lVzB5KZdHSkYFD78TpA=; b=JxczHLox+SIC/z7hjahpiRbp4MQ7yD8ourFfeRjCgKQGW2NREPSmqc3Q83kha5ZiVcFNTQddwwB8I6hyULU7+bgMnjBAKZbI+5rwnSrtaZsJXBFT4Yh4sGHJWizmT2wgluYT9eBcRzCtT1s/dWzFX1yO47+A6qAsBk3qg/QSf6GZfgPJWxRQcl3byNQDq9d1+Bj1xkX5Rgx3RtvD9VdDHwL8J0qnZBFTuJURYFIaO3enA46isNHOTEBFqJbM4GqpUVwhLg48npZ7ulcX2OEOiPk6fswZpT4hNXVuydfPMvAQqWyZKaIBEKSr8Ncg9/nYXgN0Ws3cbGtLX8YIkb/KHw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GkcPHbpVbcg8+l6wDoBtpgB5lVzB5KZdHSkYFD78TpA=; b=DOkV4q75VvMAQvX0BSzDBptptvvq/b9aVGYfQ7NAKwACDnG4n7z4+ovvtAm11G8rIAygmyTUxfcOBN06cKQil3RDqZdkXzjFxjL5G8+YDZqmhGSRNVBp/OLkjQT0gKt5p0VEYULDrstMjOw6s5d7U3YAl+iiYHXkHv3hSbRQLQ0= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Received: from MN2PR12MB4301.namprd12.prod.outlook.com (2603:10b6:208:1d4::22) by MN2PR12MB4240.namprd12.prod.outlook.com (2603:10b6:208:1d3::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.30; Tue, 28 Feb 2023 16:14:47 +0000 Received: from MN2PR12MB4301.namprd12.prod.outlook.com ([fe80::80ae:e5ed:4fa7:2ad7]) by MN2PR12MB4301.namprd12.prod.outlook.com ([fe80::80ae:e5ed:4fa7:2ad7%9]) with mapi id 15.20.6134.030; Tue, 28 Feb 2023 16:14:47 +0000 Message-ID: <03a21986-8c76-e9c8-a3d1-d688b9b4b552@amd.com> Date: Tue, 28 Feb 2023 16:14:41 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Content-Language: en-US To: Bruce Richardson Cc: "Zhang, Qi Z" , "Liu, Mingxia" , "dev@dpdk.org" , "Xing, Beilei" , "Zhang, Yuying" , "Wu, Jingjing" References: <7450f46b-fc91-8a1e-c9f7-90ff1ca56d8e@amd.com> <57607ef8-8be6-967b-9f65-78a63e4e905c@amd.com> <4ffc2fe6-50ea-4853-3dbb-616006d0d09e@amd.com> From: Ferruh Yigit Subject: Re: [PATCH v7 18/21] net/cpfl: add HW statistics In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P265CA0161.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9::29) To MN2PR12MB4301.namprd12.prod.outlook.com (2603:10b6:208:1d4::22) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN2PR12MB4301:EE_|MN2PR12MB4240:EE_ X-MS-Office365-Filtering-Correlation-Id: 46b9d76d-b8ef-429b-9228-08db19a6e909 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: MVqdKT7FF0LhsRoNO+0hAMVoGOmw+Bz3hQ7XmWAVexamQGr0LSaBlevVtFkSq3gg0rBL4GB3FjcZXrAlFbZd+1arjLz+m9EvMudrL7z/WhLr54+Au6miH3cuGmfc7wc34aMIMhc+zJgg1IZsTTarXNV3O0Tf4ml9Wdi2QA7ejK6Fj8C/MZCa9tqunHTNGL2wOM4ONrs7ThjWx8Qnfwo/QXHt3xpdd+sRz34ON0DZhkTsXBQoNu7w9SHFdknlM9xVfWcDhJz6QN6dnMZdP35X4LjJvZCZZA77O2F0G+njLYtZ8dQVo1goVkTVAbfyViDRgpUY/6oV4IH4wJZCo4/lJvHFngR92tjOnkZoOUEN9pVbXpsAs6JZJtraH49z7k1W1gnh7mga0eRsq+KDD7lhFrOT9a6L/QWv+rVpQLro1lk3xVNb88Sj67h7aG/pS2SQhrXTY/jSAZFme9iNBE13l3Ft4Ac4dyW3RAWtp8++NIJeWuG/PR0vI28R9+fQH9CEn3gcS34mY6RAOSFv1baIIia2uXPMybJP5kb5w9QQQVDsgL2ShmDOGzQ8iWunlYYPfmnnNi7sV5hT3TMV2yCcDKT0VtutYHxj6rNEAWuiU+vIgdcSwuHeQc1phmhomvXj9o0kmzaK0YaYXszKYJ1beR7PCGcJrvieF/Xhby9icFl/MzKsLiFwyMaOq2GesVRxX4FItKI8Ulqc7M1eSXT3CS0VaMIgz4m2NCcbUG1dM4E= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR12MB4301.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230025)(4636009)(39860400002)(376002)(136003)(346002)(366004)(396003)(451199018)(31686004)(36756003)(86362001)(31696002)(66946007)(66556008)(66476007)(8676002)(5660300002)(6916009)(4326008)(41300700001)(8936002)(2906002)(44832011)(38100700002)(6666004)(6486002)(478600001)(54906003)(316002)(83380400001)(26005)(2616005)(186003)(53546011)(6506007)(6512007)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eUhrRGRYTmQ4U0xtTkpscUhkemZEb2l6TWMwb2tNRGFWWWsvemN3dXpCU2FG?= =?utf-8?B?aThtbmttdnNGQlZFdnR3MFFESjByZllwdjQ2eDdndXdnMnkxZkZGRW9Cd1pJ?= =?utf-8?B?NE1ZY1krMmp3K3I2Rkx1ZGdISDdkYTZGMDFjamhOTzc2WCszZlZ0bGZiYkx1?= =?utf-8?B?L2xHWEtWODVsODJqY1RYY2lma0Exdm9lYzRVbmlxMzBOSVQrYktoOFFmVSs4?= =?utf-8?B?UVBWWWo2L3liMU0vS1gvZmFtaFZ5Z0Q5UkFpUjl1b1FhKzRRSGNKZWxXQ1FL?= =?utf-8?B?Si9HVlBIY2FUQjRvWkZOc3I2d0d3OXQvRWdlYURkUWFvOWQybktWMkdpMWZz?= =?utf-8?B?Z1gwWHJERkp6NytXUm9VNldBOUlUSy9xby9aWTBPWk1obVFMSEU5ZHRRRUNK?= =?utf-8?B?YUsxOE9JL0s3T05mU3RINzVNYVpmVXRuZkU0czZIZHc3bUNOMWFPdW52Qzl5?= =?utf-8?B?SWtyTmxYR3lZYktXQklYWlFmRXdsbUEzSzJFTUJxbVlnRW5nZTFINy9UV1pJ?= =?utf-8?B?ZVNPSzIxemtFQU5nUmJIMDhXSE13T2ZnQi9mbUswRU9lc0UyNHhpNVByTnJv?= =?utf-8?B?dXQ4QktwZzUzbFYvc1NxTk5nL09HdUtsZW0zRmNoSjVDamhFVkMwdzBkVksv?= =?utf-8?B?cHIzUnBESklSdmR0QzUyeFpLRU5IdFFuSWF1ZjFoOHVIN25SNE43NWhmaFdN?= =?utf-8?B?MDNzT2pTeHZuaVloVVpTQ3dFVEpuZ29TeFJha1JwM2pwYWtISlpuaGlYdWxJ?= =?utf-8?B?bzliTmpwbEtpMVNBVS81Q08weEpEZmdhSVU2WVhNZmhyU2hUSWtwWCsrR0Jr?= =?utf-8?B?cExzNzdkZkxXVHBUNndHSFhYUmtSbjRxbjJ0QkhiRm1SdmlnUHJYV1I5MGxU?= =?utf-8?B?K2FDRDZsOHM4a0dpdDZQa015REQ5VVhsajdjakl0Z0FPSFZnR3BqSDYxR2tJ?= =?utf-8?B?WjJoSjlaUlpXbGU5S0o5Z2JWbHZ5dXFKalZjRndPNElkYWZQTGl1Qy94QXpj?= =?utf-8?B?T0xZTWgrdWtMK0lUVWZGR1BKVllROUE1alFtSG5EUXJUMEgvTUZVK3NYYVJv?= =?utf-8?B?Z1JuQTgwdDkyUTJmc2sxR3QvZmJXbkVKTGhMenloSE5hdTFHVTIraUxFN3Q3?= =?utf-8?B?UEdRUWM3WUxQUVAvb25oRHl3TjFzam51SkQvcTd1MGxPMm9NT0VEVUZGMDBl?= =?utf-8?B?RmVBMkNjZHJiRHhLVjFtMEN6STIvd3NLMnRIODV3NkMybHFpcXhoQWk0T3Bs?= =?utf-8?B?MzBQcjdVUUtxOCs4a1kxb1Btb3BCbVBwUkcxT1hmS2RWR0pWYTZSVE9uUWUv?= =?utf-8?B?U3JmYXVjU0owamdoUmhETFVLa3l4aWNkUnRFSmthMHR6QkdLODIyd0krcTlU?= =?utf-8?B?TmI5c3U1Z0F4WG4vcDl2OGdWbGZhcFdvQjg5UXgwMTRhTmNybkZWOWpvSXQ0?= =?utf-8?B?ZmFaZ2V3cVI1citXZzlpVnBMbG45RGdaekFrYWVrekZkTVVCeTEyM3o0eTYz?= =?utf-8?B?OTRnMWx5Y0VLekJueWFyb1ZnWjIrNnMyYVJWcktEd0twWFZJREFYbEY0Q3Rr?= =?utf-8?B?bldYOGNZY2hjQUZjdktRWU1tREhaTVZaYytyVThidEY3RWpJRW8zbkkwNjM1?= =?utf-8?B?d0xOU045SVVSWFJjL2xsVXZvWnZVVlpGaTg5WU5CbVZ1clBNdlV2dGpUNjY2?= =?utf-8?B?ZTRWaXkvOW5lV0ZKdVloS2NURG8yZlRQYWZIN2FBd2M3V3JZZnhQb0xhaE53?= =?utf-8?B?dmlRRG1WREd0cE9HcG5hRFFtMXVQRnZvNUJxQkpCTVl6bXNhU3hObWplT1BT?= =?utf-8?B?VlNnV2UwZzk0NWUzSGlaRklyWldybWwrWTdJZEc3UDVMRDBoZlFGeWs1eGhM?= =?utf-8?B?clFhb0pyUUdLSlJvdlI2NU1PS3Q3bXg0bWJQNUNpc1EzR3lZLzJQZUdNTTA4?= =?utf-8?B?QWtEeFlXRDJyVkxGUmRGcDIvb0FwS0haVURySXczL3Z2SW4vZ0kvWWRPSFFN?= =?utf-8?B?SEJJTG1BaFF5RlZFWnhRTFlzMFhkd1BpV2dhRi9WTTNNeTZ5NHg2Y1c0U3BP?= =?utf-8?B?VzhEaTZOQU9vQWpFWUdzcUJMM2ozQkFxKzl2MzhqYWJMMGk2WG1HV09OK2ZY?= =?utf-8?Q?vkmiejBhLcd3eReaiIckxAZSq?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 46b9d76d-b8ef-429b-9228-08db19a6e909 X-MS-Exchange-CrossTenant-AuthSource: MN2PR12MB4301.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Feb 2023 16:14:47.0540 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: AUTHfLdNfiYBzMKj9cXJFVDV6wsHK/9MYpDpY3FejjGpPerY3F7CLT5CJhqnFSVK X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4240 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 2/28/2023 2:24 PM, Bruce Richardson wrote: > On Tue, Feb 28, 2023 at 01:34:43PM +0000, Ferruh Yigit wrote: >> On 2/28/2023 1:29 PM, Zhang, Qi Z wrote: >>> >>> >>>> -----Original Message----- >>>> From: Ferruh Yigit >>>> Sent: Tuesday, February 28, 2023 8:33 PM >>>> To: Richardson, Bruce >>>> Cc: Liu, Mingxia ; dev@dpdk.org; Xing, Beilei >>>> ; Zhang, Yuying ; Wu, >>>> Jingjing >>>> Subject: Re: [PATCH v7 18/21] net/cpfl: add HW statistics >>>> >>>> On 2/28/2023 12:24 PM, Ferruh Yigit wrote: >>>>> On 2/28/2023 12:12 PM, Bruce Richardson wrote: >>>>>> On Tue, Feb 28, 2023 at 12:04:53PM +0000, Ferruh Yigit wrote: >>>>>>> On 2/28/2023 11:47 AM, Liu, Mingxia wrote: >>>>>>> >>>>>>> Comment moved down, please don't top post, it makes very hard to >>>>>>> follow discussion. >>>>>>> >>>>>>>>> -----Original Message----- From: Ferruh Yigit >>>>>>>>> >>>>>>>>> Sent: Tuesday, February 28, 2023 6:02 PM To: Liu, Mingxia >>>>>>>>> ; dev@dpdk.org; Xing, Beilei >>>>>>>>> ; Zhang, Yuying >>>>>>>>> Subject: Re: [PATCH v7 18/21] net/cpfl: add HW statistics >>>>>>>>> >>>>>>>>> On 2/28/2023 6:46 AM, Liu, Mingxia wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- From: Ferruh Yigit >>>>>>>>>>> >>>>>>>>>>> Sent: Tuesday, February 28, 2023 5:52 AM To: Liu, Mingxia >>>>>>>>>>> ; dev@dpdk.org; Xing, Beilei >>>>>>>>>>> ; Zhang, Yuying >>>>>>>>>>> Subject: Re: [PATCH v7 18/21] net/cpfl: add HW statistics >>>>>>>>>>> >>>>>>>>>>> On 2/16/2023 12:30 AM, Mingxia Liu wrote: >>>>>>>>>>>> This patch add hardware packets/bytes statistics. >>>>>>>>>>>> >>>>>>>>>>>> Signed-off-by: Mingxia Liu >>>>>>>>>>> >>>>>>>>>>> <...> >>>>>>>>>>> >>>>>>>>>>>> +static int +cpfl_dev_stats_get(struct rte_eth_dev *dev, struct >>>>>>>>>>>> rte_eth_stats +*stats) { + struct idpf_vport *vport = + >>>>>>>>>>>> (struct idpf_vport *)dev->data->dev_private; + struct >>>>>>>>>>>> virtchnl2_vport_stats *pstats = NULL; + int ret; + + ret = >>>>>>>>>>>> idpf_vc_stats_query(vport, &pstats); + if (ret == 0) { + >>>>>>>>>>>> uint8_t crc_stats_len = (dev->data- dev_conf.rxmode.offloads & >>>>>>>>>>>> + >>>>>>>>>>>> RTE_ETH_RX_OFFLOAD_KEEP_CRC) ? >>>>>>>>>>> 0 : >>>>>>>>>>>> + RTE_ETHER_CRC_LEN; + + >>>>>>>>>>>> idpf_vport_stats_update(&vport->eth_stats_offset, pstats); + >>>>>>>>>>>> stats->ipackets = pstats->rx_unicast + pstats->rx_multicast + + >>>>>>>>>>>> pstats->rx_broadcast - pstats->rx_discards; + >>>>>>>>>>>> stats->opackets = pstats->tx_broadcast + pstats->tx_multicast >>>>>>>>>>> + >>>>>>>>>>>> + pstats->tx_unicast; >>>>>>>>>>>> + stats->imissed = pstats->rx_discards; + >>>>>>>>>>>> stats->oerrors = pstats->tx_errors + pstats->tx_discards; + >>>>>>>>>>>> stats->ibytes = pstats->rx_bytes; + stats->ibytes -= >>>>>>>>>>>> stats->ipackets * crc_stats_len; + stats->obytes = >>>>>>>>>>>> pstats->tx_bytes; + + dev->data->rx_mbuf_alloc_failed = >>>>>>>>>>>> +cpfl_get_mbuf_alloc_failed_stats(dev); >>>>>>>>>>> >>>>>>>>>>> 'dev->data->rx_mbuf_alloc_failed' is also used by telemetry, >>>>>>>>>>> updating here only in stats_get() will make it wrong for telemetry. >>>>>>>>>>> >>>>>>>>>>> Is it possible to update 'dev->data->rx_mbuf_alloc_failed' >>>>>>>>>>> whenever alloc failed? (alongside 'rxq->rx_stats.mbuf_alloc_failed'). >>>>>>>>>> [Liu, Mingxia] As I know, rte_eth_dev_data is not a public >>>>>>>>>> structure provided >>>>>>>>> to user, user need to access through rte_ethdev APIs. >>>>>>>>>> Because we already put rx and tx burst func to common/idpf which >>>>>>>>>> has no >>>>>>>>> dependcy with ethdev lib. If I update >>>>>>>>> "dev->data->rx_mbuf_alloc_failed" >>>>>>>>>> when allocate mbuf fails, it will break the design of our >>>>>>>>>> common/idpf >>>>>>>>> interface to net/cpfl or net.idpf. >>>>>>>>>> >>>>>>>>>> And I didn't find any reference of 'dev->data->rx_mbuf_alloc_failed' >>>>>>>>>> in lib >>>>>>>>> code. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Please check 'eth_dev_handle_port_info()' function. As I said >>>>>>>>> this is used by telemetry, not directly exposed to the user. >>>>>>>>> >>>>>>>>> I got the design concern, perhaps you can put a brief limitation >>>>>>>>> to the driver documentation. >>>>>>>>> >>>>>>>> OK, got it. >>>>>>>> >>>>>>>> As our previous design did have flaws. And if we don't want to >>>>>>>> affect correctness of telemetry, we have to redesign the idpf >>>>>>>> common module code, which means a lot of work to do, so can we >>>>>>>> lower the priority of this issue? >>>>>>>> >>>>>>> I don't believe this is urgent, can you but a one line limitation to >>>>>>> the documentation for now, and fix it later? >>>>>>> >>>>>>> And for the fix, updating 'dev->data->rx_mbuf_alloc_failed' where >>>>>>> ever 'rxq->rx_stats.mbuf_alloc_failed' updated is easy, although you >>>>>>> may need to store 'dev->data' in rxq struct for this. >>>>>>> >>>>>>> But, I think it is also fair to question the assumption telemetry >>>>>>> has that 'rx_mbuf_alloc_fail' is always available data, and consider >>>>>>> moving it to the 'eth_dev_handle_port_stats()' handler. +Bruce for >>>> comment. >>>>>>> >>>>>> >>>>>> That's not really a telemetry assumption, it's one from the stats, >>>>>> structure. Telemetry just outputs the contents of data reported by >>>>>> ethdev stats, and rx_nombuf is just one of those fields. >>>>>> >>>>> >>>>> Not talking about 'rx_nombuf' in 'eth_dev_handle_port_stats()', but >>>>> talking about 'rx_mbuf_alloc_fail' in 'eth_dev_handle_port_info()', >>>>> >>>>> should telemetry return interim 'eth_dev->data->rx_mbuf_alloc_failed' >>>>> value, specially when 'rx_nombuf' is available? >>>>> >>>>> Because at least for this driver returned 'rx_mbuf_alloc_fail' value >>>>> will be wrong, I believe that is same for 'idpf' driver. >>>>> >>>>> > > Thanks for the clarification, the question is clearer now. Having duplicate > info seems strange. > >>>> >>>> Or, let me rephrase like this, >>>> 'eth_dev->data->rx_mbuf_alloc_failed' is not returned to user directly via >>>> ethdev APIs, but it is via telemetry. >>>> >>>> I think it is not guaranteed that this value will be correct at any given time as >>>> telemetry assumes, so should we remove it from telemetry? >>> >>> May not be necessary, PMD should be able to give the right number, this is something we can fix in idpf and cpfl PMD, to align with other PMD. >> >> Thanks Qi, Ok to have drivers aligned to common usage. >> >> Still, for telemetry we can consider removing 'rx_mbuf_alloc_fail', user >> can get that information from 'rx_nombuf'. > > I would agree with Ferruh. The information on nombufs should be available > just from the stats. It doesn't logically fit in the "info" category, > especially when it is in stats already. > Thanks Bruce. So, no need to update driver(s) related to 'rx_mbuf_alloc_fail', existing patch is good. I will send ethdev telemetry change later, it is a minor change.