From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 5609441D9D;
Tue, 28 Feb 2023 15:24:21 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id F186E410D4;
Tue, 28 Feb 2023 15:24:20 +0100 (CET)
Received: from mga07.intel.com (mga07.intel.com [134.134.136.100])
by mails.dpdk.org (Postfix) with ESMTP id 655344021F
for <dev@dpdk.org>; Tue, 28 Feb 2023 15:24:19 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
t=1677594259; x=1709130259;
h=date:from:to:cc:subject:message-id:references:
in-reply-to:mime-version;
bh=fbe11lwRsV+S5u6Z8x4FfqDCLghOvVpbEvBX7ZeY9cc=;
b=dyvgiqgT0OuK8rM53HAW3w+arMnprKXU3nY0+gzHBIpj2MrfJdWOtMz9
7Abx4Cj1n7/JaiBEF9YAkMbuwLpZ0dqzwZ8wUILrLC1z/Wz2bIt9V34hh
7TsVTeQTZHAHf1Yc0PQpNuGOwMMxB1bhztBjtlc8jS750P9BPFuTcfife
N5YiiAiYBGBThPyOP5FnJGMhP70zGDgWwG9KXEkMPhgX8Z5abjqJDklAL
DrcSBSZTlaF3nTDY+MhLJ4eJTCIJbqC9ep+rnDwhWykTkbF7aLWqwof24
8D4mtUJ6JCVhPiqbMchOPTuObODKIvidjWUj5+KNhlTv0Wzx5lCe+p6z+ A==;
X-IronPort-AV: E=McAfee;i="6500,9779,10635"; a="398924095"
X-IronPort-AV: E=Sophos;i="5.98,222,1673942400"; d="scan'208";a="398924095"
Received: from fmsmga007.fm.intel.com ([10.253.24.52])
by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
28 Feb 2023 06:24:18 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=McAfee;i="6500,9779,10635"; a="676319938"
X-IronPort-AV: E=Sophos;i="5.98,222,1673942400"; d="scan'208";a="676319938"
Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16])
by fmsmga007.fm.intel.com with ESMTP; 28 Feb 2023 06:24:17 -0800
Received: from orsmsx611.amr.corp.intel.com (10.22.229.24) by
ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.2507.16; Tue, 28 Feb 2023 06:24:17 -0800
Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) by
orsmsx611.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.2507.16 via Frontend Transport; Tue, 28 Feb 2023 06:24:17 -0800
Received: from NAM02-BN1-obe.outbound.protection.outlook.com (104.47.51.46) by
edgegateway.intel.com (134.134.137.103) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.1.2507.16; Tue, 28 Feb 2023 06:24:17 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=P+vpIf5iYZgvlujYYNDPdzSlLiC7YP1AixjxcPq1rNOXarmu7r0osTR5XYMr5bcYxZmiR8KEPXuhJrP38y7kk0I9hfrDLTEZZqVPLzpetM4xqLaun6rZN+JL8xiHEu7Dvcy6bbxDEZ9S0f16EWmvMSqggl4HJ4t2E6jPQm7RIKOlKrWUrfR2zMTXXWaEGSy0HnDW6G/ze2q3CYSy70sIgCpLVnQC1PSVwbijmKETVzNC0YQh1erGlrvbCTIW4Zh8gCd88W6AnGyBtnskSlloLMkHWf5KalAQfjlo+pBiorO7sF1oSRQ7qZQCqWQytlqgcY+YYAyf9ZmhTI5Urf61TQ==
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=yuICRs+JbffsnBph96VSw9jnoUU2NOqMuXeVPV0H1Vs=;
b=MYB2DoqtVPa8cCpCDV+qaq3440vibgQ7/mJFhYEkU6RqMa55PY7r6NoFD7y2lP+/hhNZtZDg3ZLEOE0UruQXrEJK+fUsix9AHSk33wzof4UU96ZFGxmYXlIvUDHVRQWsvZb6qYX2LqE982l+jpXca/PwvqsFGuEG50Bz6K1SIw4RoqmV2JMKmgC6uBwPdH8Hx9lf6CHPKcmWHt38Odel10xpjkdf5XJ5E2Z6uzPyFGW6DSPzNhsHwWAiPwjeb/GZoy0kalXqEpK3F1m2t7T8kv1b5TC1ip7SpKsbvZ3R/s1nJEvGfrKjaSld3Kb05qDF/IP0d0VqoAJjv6X9A7GBCg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;
dkim=pass header.d=intel.com; arc=none
Authentication-Results: dkim=none (message not signed)
header.d=none;dmarc=none action=none header.from=intel.com;
Received: from DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17)
by MN0PR11MB6301.namprd11.prod.outlook.com (2603:10b6:208:3c3::8) 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 14:24:14 +0000
Received: from DS0PR11MB7309.namprd11.prod.outlook.com
([fe80::18d0:ac53:aa1d:d19c]) by DS0PR11MB7309.namprd11.prod.outlook.com
([fe80::18d0:ac53:aa1d:d19c%9]) with mapi id 15.20.6134.030; Tue, 28 Feb 2023
14:24:14 +0000
Date: Tue, 28 Feb 2023 14:24:06 +0000
From: Bruce Richardson <bruce.richardson@intel.com>
To: Ferruh Yigit <ferruh.yigit@amd.com>
CC: "Zhang, Qi Z" <qi.z.zhang@intel.com>, "Liu, Mingxia"
<mingxia.liu@intel.com>, "dev@dpdk.org" <dev@dpdk.org>, "Xing, Beilei"
<beilei.xing@intel.com>, "Zhang, Yuying" <yuying.zhang@intel.com>, "Wu,
Jingjing" <jingjing.wu@intel.com>
Subject: Re: [PATCH v7 18/21] net/cpfl: add HW statistics
Message-ID: <Y/4OhjgqJ62q9FET@bricha3-MOBL.ger.corp.intel.com>
References: <a0d6f50f-e5c1-d18e-a427-937771c54b82@amd.com>
<PH0PR11MB5877099D272F77C86AD95DBAECAC9@PH0PR11MB5877.namprd11.prod.outlook.com>
<7450f46b-fc91-8a1e-c9f7-90ff1ca56d8e@amd.com>
<PH0PR11MB58778195BD767ED30BBE5578ECAC9@PH0PR11MB5877.namprd11.prod.outlook.com>
<cb64da4e-59ec-357a-cc19-ff43a3484f50@amd.com>
<Y/3vs+Nu5kMcdlk9@bricha3-MOBL.ger.corp.intel.com>
<57607ef8-8be6-967b-9f65-78a63e4e905c@amd.com>
<4ffc2fe6-50ea-4853-3dbb-616006d0d09e@amd.com>
<DM4PR11MB5994FEDD56998FA612DA01F0D7AC9@DM4PR11MB5994.namprd11.prod.outlook.com>
<f8484a4d-ed2e-177f-7b73-a4777460f474@amd.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <f8484a4d-ed2e-177f-7b73-a4777460f474@amd.com>
X-ClientProxiedBy: LO4P123CA0253.GBRP123.PROD.OUTLOOK.COM
(2603:10a6:600:194::6) To DS0PR11MB7309.namprd11.prod.outlook.com
(2603:10b6:8:13e::17)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS0PR11MB7309:EE_|MN0PR11MB6301:EE_
X-MS-Office365-Filtering-Correlation-Id: 70103fbd-9b9f-4292-da7b-08db199777d3
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: fhyupthhNz21I0XjOb/cc7Yuxo5Yp8ABMowET4g3Pr6+P71c2SyobMRhhSD7Ai5jQcoIEYJKlkoQwjmNUWAYcH1L93OXYgSGYxpgTQlCvygCPCmce5bjU9qa3tBCxt4YNKvYK8gN0zWWghPdvHolokq71T9exrxnYK7Nvhvvo32qLvQhh9ZKrTAV79K5RV+MkcQpaVFQ5cdlLsx/nrkteqr8n5WN+eawd5JrPTsEkf6fq0o5EANf4b8zuibyAZFddq9a4oCO385ti2chTBk6VFv/Tq7O6y7d2ak0i7cDcwJ5/AB6UBGUYm/GXY/ukHCWu7RmpNtfIKbduRw8iWoRVjK1ivTcfRILGkyAoToFsNnplZVKcJLDonQ5TUKpM1ZxG9lJmHbv2JJwycHMAYRsRpoZNXuFeYMMH9F2Q0LlHFGrAmv+86Ebr0J9TKFZqDnF/Vs3IiC5po6E4FauTLynS8DpDJyHWDvjdA4MnocryeYtyn0rgKwX84Aqh/gL0DIr92Nhorh1dBx6pZXZ6ChidH9xlVyTtvxYbJQorl5DrapyrmJ+RlBKjL/pNc+wFabFo/dnKg3c7KCQwHpg362CzpPRTrfCX0Crir15atEHlTxWfvkqVAhpQdg71kXECi3+53Ea5ruuantqe099G8vRVA==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
IPV:NLI; SFV:NSPM; H:DS0PR11MB7309.namprd11.prod.outlook.com; PTR:; CAT:NONE;
SFS:(13230025)(136003)(346002)(376002)(396003)(39860400002)(366004)(451199018)(86362001)(66946007)(66556008)(66476007)(41300700001)(8676002)(5660300002)(8936002)(6916009)(4326008)(2906002)(44832011)(82960400001)(38100700002)(6666004)(107886003)(6486002)(478600001)(54906003)(316002)(83380400001)(186003)(26005)(53546011)(6512007)(6506007);
DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?ZK+D8SR4GKLRgetwx7iwnQDlhGBjl6YMUwcwadfg7Df10ysagfGeXXUI7ATz?=
=?us-ascii?Q?QPvhj1rARrQ0353sx48ZVrceniv0AjCaYmlhf29vP0sFjxkYyS0JWY7taja9?=
=?us-ascii?Q?JgntdXpus8CF4tvZcckMjIQlW9tbIStJ3Z8MpHuO8PUcI45GTmcMJ20RKuU1?=
=?us-ascii?Q?IGPRoNPQjrlv31rqWlQ/IPYlxDdLZdgMha3WTfi2pQ0QA7F1j5YFILuzdw6G?=
=?us-ascii?Q?v+Z4suz5R27etYS8lNvqImasnSZbt0aDpqgvEqWr3Gt+5CQrh3ZlLiWcD8dO?=
=?us-ascii?Q?F9YVJAx7v0pXwaotY+Hewnunkt1mWnOvYuINAejwVtGn3XLVkoZ2lQ/oeBfJ?=
=?us-ascii?Q?qdID5+UtC9l7SadOw63YZfoU6dgmKoCP6g01r8Z772dbeZ8Fo2lxrarTADeY?=
=?us-ascii?Q?xhgxwx+IRGLpJMGKdWl+8UtU8QMZLP5xIn7KTkpnOVu424JsWYG3LvrX2n1d?=
=?us-ascii?Q?7Vv/m6wdbrZ9DQveIwnfo3O6ChhSeopQYjFA3aneSRMo2kia7ZRBmxHINmb6?=
=?us-ascii?Q?kydxb2mRyUMm2zEzAYuNiMNawhtvx1TRiw9vzviHvTtw4aeNx2u9VXZpKL94?=
=?us-ascii?Q?mUl/BwWan8+oh2Wf0m2JUFrVYWb96A4pTsWmkIk5BRpXWzdKsdaGRjKxXsiY?=
=?us-ascii?Q?9cHMPAVP0TQBTmVXpXOiN9Pzj94I1Sv6RlsocX4Lw09N8FXaLPdhIFfvS36o?=
=?us-ascii?Q?5BUAHO+RfbEFmPhnTZlmiYyayRBoRzfpnkphcZbgm187JDi1tuemeQOMczxG?=
=?us-ascii?Q?+jNiChnEutQH+S1NEIvr/NCXov7/tBqmZYIvGNwfJfDP6Yc6LuwkrsGcOtYA?=
=?us-ascii?Q?A1RdSioRbdIescmi26N+vF7kpU3D9cp1NRdMTYzZrl2w5yiK2GFDV5nt2A/e?=
=?us-ascii?Q?nF6eO/6tYS3EScWbjT0YJzRN0GFH/NgrIZ5+vDAPw3+X2Hydt34n4aAsNHuj?=
=?us-ascii?Q?IUTmZMTpEV0I011SJ5uZ64cYBb0WRMoyum4Hiidjl1SClOBCfCAsCSgofVoe?=
=?us-ascii?Q?42yFJN+mbXeVPo7+c3ynRZYdg44NrgU+cH65L4045QvP8rma7lzS5lqW7VvQ?=
=?us-ascii?Q?Eh67NPC+Rps08UePgcAZVSHW0LsvlHGLnxymqVzo+/hhtXNkPIu8T2tx3mnE?=
=?us-ascii?Q?EDJcmtPr0eHFdw/WCdj5chAFw6dNkuhh0gTrya7s3A025V5/LVk94dG1n1Z6?=
=?us-ascii?Q?enLIPHst6i0syat4kzYgtpVJ30sXdnRFDjfMSmSwXIGtCMBcYiYMBcftgPb7?=
=?us-ascii?Q?fhtkDG9jZEYAZVU5heXypj8t1VcsSvJDSCMCVAkBeFFfzK/slavWO0JV1K41?=
=?us-ascii?Q?F6mfZNl4GYJscQTMSfDhlSQaPwOrme1JkOcoPYzs6n3YJmRP7VEhEWF/6A98?=
=?us-ascii?Q?YyoYh5Chcp6RfUDXLA92XsVPCq0e4uE7k22w6MRXNEDQMy139a2LlkGTTasm?=
=?us-ascii?Q?wwltdpJ5JP7Z3sjqZd6NfUjTagUtF7vQrxqKJ2eZEFS5Dnshfx2MUMvaxSKF?=
=?us-ascii?Q?czidyz3A9dXddk8WOwbLGP/ZIfWuKRyyar7EI1jtmeeUtDX8rGfo5q0Wnd6d?=
=?us-ascii?Q?Z0qcgA/4ReH5LAKkeFvDVWspDNIupZa984xJK6BnrP/DeSzxmtvWoK47sgMc?=
=?us-ascii?Q?mA=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 70103fbd-9b9f-4292-da7b-08db199777d3
X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7309.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Feb 2023 14:24:14.6998 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: jD8e08/zI0SsBlK+v/dcTVKF3FwoXjN3abHIg8u8iMRm+c5n7xHhZk8G01XRxUpoyotOhK3ScDPE+O+2StFrMvlhtmqMuvdjeV2g3px8pck=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR11MB6301
X-OriginatorOrg: intel.com
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
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
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 <ferruh.yigit@amd.com>
> >> Sent: Tuesday, February 28, 2023 8:33 PM
> >> To: Richardson, Bruce <bruce.richardson@intel.com>
> >> Cc: Liu, Mingxia <mingxia.liu@intel.com>; dev@dpdk.org; Xing, Beilei
> >> <beilei.xing@intel.com>; Zhang, Yuying <yuying.zhang@intel.com>; Wu,
> >> Jingjing <jingjing.wu@intel.com>
> >> 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
> >>>>>>> <ferruh.yigit@amd.com>
> >>>>>>> Sent: Tuesday, February 28, 2023 6:02 PM To: Liu, Mingxia
> >>>>>>> <mingxia.liu@intel.com>; dev@dpdk.org; Xing, Beilei
> >>>>>>> <beilei.xing@intel.com>; Zhang, Yuying <yuying.zhang@intel.com>
> >>>>>>> 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
> >>>>>>>>> <ferruh.yigit@amd.com>
> >>>>>>>>> Sent: Tuesday, February 28, 2023 5:52 AM To: Liu, Mingxia
> >>>>>>>>> <mingxia.liu@intel.com>; dev@dpdk.org; Xing, Beilei
> >>>>>>>>> <beilei.xing@intel.com>; Zhang, Yuying <yuying.zhang@intel.com>
> >>>>>>>>> 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 <mingxia.liu@intel.com>
> >>>>>>>>>
> >>>>>>>>> <...>
> >>>>>>>>>
> >>>>>>>>>> +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.
/Bruce