From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <stable-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id E87B0A0C43
for <public@inbox.dpdk.org>; Thu, 30 Sep 2021 17:30:25 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id C25C94113A;
Thu, 30 Sep 2021 17:30:25 +0200 (CEST)
Received: from mga09.intel.com (mga09.intel.com [134.134.136.24])
by mails.dpdk.org (Postfix) with ESMTP id 2B77940DDA;
Thu, 30 Sep 2021 17:30:21 +0200 (CEST)
X-IronPort-AV: E=McAfee;i="6200,9189,10123"; a="225253018"
X-IronPort-AV: E=Sophos;i="5.85,336,1624345200"; d="scan'208";a="225253018"
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
30 Sep 2021 08:30:20 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.85,336,1624345200"; d="scan'208";a="618244722"
Received: from orsmsx601.amr.corp.intel.com ([10.22.229.14])
by fmsmga001.fm.intel.com with ESMTP; 30 Sep 2021 08:30:20 -0700
Received: from orsmsx611.amr.corp.intel.com (10.22.229.24) by
ORSMSX601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.2242.12; Thu, 30 Sep 2021 08:30:19 -0700
Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) 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.2242.12 via Frontend Transport; Thu, 30 Sep 2021 08:30:19 -0700
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.174)
by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.1.2242.12; Thu, 30 Sep 2021 08:30:19 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=iDGVoP6NyQKE9Ddox7+Aap+GQSWGI3V+evwpygCQDUnaEgAfFxRKklDGCwfYv2uOHmOokFK4jHLvycgWhTS4dIFVcXltckfom6R4xAZ0tMuu0OGtVQ16ojNvCJqWo0WIS2sqpJg9RaTIEpaaoVIDG1+wHe6UhAgKgBnSJou719pUraEnYhEoQdPz01Y3ghAXvsqcFHvUTVK/tyZ8kvqtVEwYsmdVu7UG4ioB3vtZ1UVygCF5zi3ANDECvXgd3WZs2QRETjxWGsaKa+rNfcB4pwzVXf3P+189/UjSlsK9BAJfMbOFXwrgcHnIZYW9Qq5GeX+AdQqzWEu7Lg+BFQzp+Q==
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;
bh=hsTVACFsXe+UPw/4luKv6QN0C8TGgPypplPnFvvKsZw=;
b=H1aomIfiFMSK3ffuutG7FkGXmyTjI7l2LU7+TNCxDwRMnL2oMnVMkmoKLPzEuM2r1wzssb+yPIGtPvqWUqfE9rXTpsLGc6m2lSxkPZWP3VKMOz94d2JGxzOxkMo732fjFalUQt6sEKU/e3Fa6ym1S5W3PHtAzn3BTDtnhRIckiwVeIueBhAzqazUIEilwg8X0rSauH2U24KHnjyontFJRau5eF8R/U+TqYWzymmc1TkWnhTILKf8ExboEQJZcOkf7OHZXbDYdqDsLMw2ad2aDgcxYifRZk48O6wQSW8qA8ZVg9rlIvUWPkOOi9hiycDN3UGLnLy8jOiihIqCDv1PPw==
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
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com;
s=selector2-intel-onmicrosoft-com;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=hsTVACFsXe+UPw/4luKv6QN0C8TGgPypplPnFvvKsZw=;
b=sBiLXVk6KJggqY9cIZ8WcH+3Xtg4b5kw5D0Rva3vBnvZ53RKWL+pZGR+Xsp566bNK8lDVidjVsO3PUx9tQYiFVRVHpkenzFOILfQW7J98CaQq8e5sRhnLxCu6tN+d7+ZMI+ARNY5Y4BSLm5h5lVaLkxrl1lR3mgMKnJ2P6lZBek=
Authentication-Results: intel.com; dkim=none (message not signed)
header.d=none;intel.com; dmarc=none action=none header.from=intel.com;
Received: from PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19)
by PH0PR11MB4791.namprd11.prod.outlook.com (2603:10b6:510:43::10)
with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.15; Thu, 30 Sep
2021 15:30:16 +0000
Received: from PH0PR11MB5000.namprd11.prod.outlook.com
([fe80::747b:3a08:d1ec:31fc]) by PH0PR11MB5000.namprd11.prod.outlook.com
([fe80::747b:3a08:d1ec:31fc%5]) with mapi id 15.20.4544.021; Thu, 30 Sep 2021
15:30:16 +0000
To: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>, Thomas Monjalon
<thomas@monjalon.net>
CC: <dev@dpdk.org>, Olivier Matz <olivier.matz@6wind.com>, Ivan Ilchenko
<ivan.ilchenko@oktetlabs.ru>, <stable@dpdk.org>, Andy Moreton
<amoreton@xilinx.com>, Kuba Kozak <kubax.kozak@intel.com>
References: <20210604144225.287678-1-andrew.rybchenko@oktetlabs.ru>
<20210928120533.834334-1-andrew.rybchenko@oktetlabs.ru>
<20210928120533.834334-2-andrew.rybchenko@oktetlabs.ru>
<a430ccd6-ef8d-68b3-3826-8fcc1f76f4d2@intel.com>
<ce651da1-0e16-cfeb-904b-613fd63e1e80@oktetlabs.ru>
<b42ebfb9-23cf-1751-d2af-df29f8f18392@intel.com>
<c6bcce29-88bf-c433-5197-5bca8a0462e4@oktetlabs.ru>
<5e9f39eb-d859-0c4a-8eb7-1c9f494364a0@intel.com>
<5d9c9565-b3cf-8e29-309f-1aa3a2e91491@oktetlabs.ru>
From: Ferruh Yigit <ferruh.yigit@intel.com>
X-User: ferruhy
Message-ID: <adb5d7c6-d74d-8337-f2d6-122cfecf2048@intel.com>
Date: Thu, 30 Sep 2021 16:30:10 +0100
In-Reply-To: <5d9c9565-b3cf-8e29-309f-1aa3a2e91491@oktetlabs.ru>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: DU2PR04CA0075.eurprd04.prod.outlook.com
(2603:10a6:10:232::20) To PH0PR11MB5000.namprd11.prod.outlook.com
(2603:10b6:510:41::19)
MIME-Version: 1.0
Received: from [192.168.0.206] (37.228.236.146) by
DU2PR04CA0075.eurprd04.prod.outlook.com (2603:10a6:10:232::20) with Microsoft
SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.4566.14 via Frontend Transport; Thu, 30 Sep 2021 15:30:15 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 44f05dda-6336-4d22-f991-08d984273455
X-MS-TrafficTypeDiagnostic: PH0PR11MB4791:
X-MS-Exchange-Transport-Forked: True
X-Microsoft-Antispam-PRVS: <PH0PR11MB479188DF98C476ACEE9313FD95AA9@PH0PR11MB4791.namprd11.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:2089;
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: rpltIKNHOlrKGNXDBGVkJHPyeaWez/iNpCbfFaSxD7Z/1b51FV70rnatR05bHg/ETzuSN6kf5BGYYAjVTFTqeOERf1ZkwXbWIdih+z8IBcAMcbOf6QunpAbUI9cUSZcHSvZE1IIndSU7tNyPhOBg+QttTnmjAbXwE3EKsRD2seuFDN7gGLu6SpZ97clEPAuv3VTk0QvJ7l/o8noCCKE56wp8gNdAXO2TBt8ZA/Gge+l7iN/bFWNxKmS9crb3tO+VnmakHS64OgE5KLGOfMznlk8ewubsnj2rFz4W0YPFmZ3CsDjNMfFFA4QwA+gjcwMkGEhhxXQbTzX6vR+HbUGTFltmSUtRJ4VLrMltTDvEEBQ+9kauLKreUb+5B6TnZmyJbzkB6/XKMQoSse4LyBSwaiSxzA6pccjNcVZEb3MTN+vw87o24yYh3Y1hw2Ogq3f/hcfFhksj8jy7ljUwwNdrCiAdYigHyzd3SKWJUlHkI3+z2CdxYsa2uxt74Dl22KjdESAizzj3yjgKgPoLWfQBWddMcQ0EUD8wAh3KfDASLJyz53UeoLLiTJG5sIQhjt2Z9N4+9k573CMPGpJoFdbH/HkRtleaO3l7Jld4wnKprQGO+pD/QNDhyFl5p+jblvAEYReswb7rCX1PW1XEctAnNn9hWfpb/kg74Bf8ZqSHh2lrvFT0o9smIilgCzY8SE36cB7FeT1LStsI1PtfxYZmmg==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
IPV:NLI; SFV:NSPM; H:PH0PR11MB5000.namprd11.prod.outlook.com; PTR:; CAT:NONE;
SFS:(4636009)(366004)(38100700002)(86362001)(110136005)(54906003)(16576012)(316002)(8676002)(83380400001)(6666004)(53546011)(66476007)(66556008)(2906002)(66946007)(31696002)(2616005)(956004)(36756003)(186003)(26005)(31686004)(4326008)(6486002)(5660300002)(44832011)(8936002)(508600001)(107886003)(45980500001);
DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZDZldkRrMkhtTE8xYjJTeUZ2VW9Wd01pbWpUeVpjcGtacVFFK21ReG9EWWJS?=
=?utf-8?B?RFJGcXZpUVdSSzFRV09UKzN0L08yc24vU2xCOSt0Z21tTGFsMmJPcyt6Q2dB?=
=?utf-8?B?R3lHQUo4OGx6M0tQV3QzZFM5aUxtaUpCWXo4WEVFY2ZHN3F2b0FQdUZheWty?=
=?utf-8?B?a0NYeHM4ZU92Rkk2cTB4L29PQTFiTUFuSlZmZlFacFh0MnJJWlU2OVVHM0Z1?=
=?utf-8?B?YW1YMnZ0S2ErbUZDRmNqcHJrb21sMEkrY282dzJSQ01rR2w5bW5DT29QVzk0?=
=?utf-8?B?b0dobGJ4bW1oWjU4d3JZMmJ2eXZrSnpiU09CdXlPWFhCZjVrU25iUFkxTk5R?=
=?utf-8?B?U1VwcUFUWDhiaUJKWFplZ1VwbFdLVlJVYlVuTDF6dHZDd05mK2lLZldyU1Ji?=
=?utf-8?B?TDQrT25TbjBUSWU3VUVNc1BtbjM1SDdXN2IwTG1ER0hMN3hkZi80L1NGc1dQ?=
=?utf-8?B?N08xcEIxc1lObUEvS2RCNXhMRC84OExjaGJ5RWJkS3pXNHpKbXc2SFFhRjBD?=
=?utf-8?B?MTFRNmZsYW5rRVdJUmZjNk5BeDhWcXBLUHBVaUkzSXEwZkNYdjkrdkVta3k3?=
=?utf-8?B?dThLbjBlSkhrNDVJd3Z6UisrV3RRVGprOHBMY3dtQU1XcVdIbDBsQ3pKNGsw?=
=?utf-8?B?dXkyWkNyT1RmWHYrZ3Zod1k0YlpJeGtIUDNTYU9sdWtuZVZyb1Eyd29GUnoy?=
=?utf-8?B?aEhJbm4ySkg2RFhIVFRaVnZDNFY5bUlOZ2VaTWZrd21zeUlHeU84T1hOYTRF?=
=?utf-8?B?b1lWcVF2bzJlbjM2b2NiTEgzTWdvcVNZRW1keUhLNmVsOTBJcXBuaFA5N013?=
=?utf-8?B?aGtrajVxOUxhclNRY0RLaVlyYzZxL1FDaUJwd3Z3L2E0UTFNR0NkN1lVWWZP?=
=?utf-8?B?VURiTTFVZVEvV0RzMGdqVzQrbTcyaDQ0VDdIem11M05wbFJZNzYrdHZTNWJK?=
=?utf-8?B?U0ZLdXZKV2JoTVQ2TzRoZVpYaW5CQVFxa0VkUXFzb01CNkRsU2RmUnNmMnZ5?=
=?utf-8?B?eTB0TDdjVnh2UGtpWTFsQnI1eEw5bFIrK2Q1RXB4UW5zTDlHWkd2c3F4eSsr?=
=?utf-8?B?TGRnM3RjRXlyb0xSZllBZS81Y3V6OWNKbjVmOExEWGc5NmxPNUhKdEtwRW1D?=
=?utf-8?B?TG9GRHJHZ1pnZm1XUXkxQ1NNOThCd093RExvUnd4aE16d09rMC9lTjZhK21r?=
=?utf-8?B?aDhkejYyVUR3eXo2aVlzNzVyM3lvNEVmVk1lanRBcWxCZzlkODZUYVZqWEx4?=
=?utf-8?B?WU9MWkljNzVhVmpOYjZEYW5MVGxqSGl5SjZNVERWTUdiSmhhK3FHVHZyTTBT?=
=?utf-8?B?SU1xb2FhcEtxa015ZUY0VTJqbHBQNVZsL3ZPbC8xM1J1YmROQkVXZzdKTzAx?=
=?utf-8?B?amViOEY5bVlvQVZtaVJDQTFsUE5HTW8vcFRnNmpvRGRRbWpUM0tNdU52Znl2?=
=?utf-8?B?MWVLUlBtV0t0c3ZCMlhJbEc0VmE5VlRSeXZhTzRYZE8yS1d2T1NBTEtLMGpq?=
=?utf-8?B?UVg5SEVoQy9pT2xUYi9TYWgyYVE4b05STThjOGVOSUVmZzJWYmhETHdPTGhq?=
=?utf-8?B?MkFvV2FzNjhaK0FFc1RmclFTaU1NZWVLQzBzYUhVQzlXaFo0OW5BN3V1eW1F?=
=?utf-8?B?Y21kelQ2SlJaQy9FMExPSHVlZFdmLzAzZ29VdGZjK2FCNmNYcStmZ3hJa2JD?=
=?utf-8?B?cldpT00rZWhBZ3pSMnd0Zk1jaERkM254UVU3ZVNnVXZjNllacjN4WjY5ODRC?=
=?utf-8?Q?av0M60yEo+Xw142jKB7AFqBMjh7gWzSAAjFG1T+?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 44f05dda-6336-4d22-f991-08d984273455
X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5000.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Sep 2021 15:30:16.8148 (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: 9zNwRVOifOUI++V1vlXmOh/YCFBnGod3g8rzFktwNSAu9Dzd6kTh99hBgUvkK8ruwUhlBWwu4TeByKBDYoUmWQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4791
X-OriginatorOrg: intel.com
Subject: Re: [dpdk-stable] [PATCH v5 2/2] ethdev: fix docs of drivers
callbacks getting xstats by IDs
X-BeenThere: stable@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: patches for DPDK stable branches <stable.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/stable>,
<mailto:stable-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/stable/>
List-Post: <mailto:stable@dpdk.org>
List-Help: <mailto:stable-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/stable>,
<mailto:stable-request@dpdk.org?subject=subscribe>
Errors-To: stable-bounces@dpdk.org
Sender: "stable" <stable-bounces@dpdk.org>
On 9/30/2021 3:01 PM, Andrew Rybchenko wrote:
> On 9/30/21 3:08 PM, Ferruh Yigit wrote:
>> On 9/29/2021 12:54 PM, Andrew Rybchenko wrote:
>>> On 9/29/21 11:44 AM, Ferruh Yigit wrote:
>>>> On 9/28/2021 5:53 PM, Andrew Rybchenko wrote:
>>>>> On 9/28/21 7:50 PM, Ferruh Yigit wrote:
>>>>>> On 9/28/2021 1:05 PM, Andrew Rybchenko wrote:
>>>>>>> From: Ivan Ilchenko <ivan.ilchenko@oktetlabs.ru>
>>>>>>>
>>>>>>> Update xstats by IDs callbacks documentation in accordance with
>>>>>>> ethdev usage of these callbacks. Document valid combinations of
>>>>>>> input arguments to make driver implementation simpler.
>>>>>>>
>>>>>>> Fixes: 79c913a42f0 ("ethdev: retrieve xstats by ID")
>>>>>>> Cc: stable@dpdk.org
>>>>>>>
>>>>>>> Signed-off-by: Ivan Ilchenko <ivan.ilchenko@oktetlabs.ru>
>>>>>>> Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>>>>>> Reviewed-by: Andy Moreton <amoreton@xilinx.com>
>>>>>>> ---
>>>>>>> lib/ethdev/ethdev_driver.h | 42 ++++++++++++++++++++++++++++++++++++--
>>>>>>> 1 file changed, 40 insertions(+), 2 deletions(-)
>>>>>>>
>>>>>>> diff --git a/lib/ethdev/ethdev_driver.h b/lib/ethdev/ethdev_driver.h
>>>>>>> index 40e474aa7e..c89eefcc42 100644
>>>>>>> --- a/lib/ethdev/ethdev_driver.h
>>>>>>> +++ b/lib/ethdev/ethdev_driver.h
>>>>>>> @@ -187,11 +187,28 @@ typedef int (*eth_xstats_get_t)(struct rte_eth_dev *dev,
>>>>>>> struct rte_eth_xstat *stats, unsigned int n);
>>>>>>> /**< @internal Get extended stats of an Ethernet device. */
>>>>>>>
>>>>>>> +/**
>>>>>>> + * @internal
>>>>>>> + * Get extended stats of an Ethernet device.
>>>>>>> + *
>>>>>>> + * @param dev
>>>>>>> + * ethdev handle of port.
>>>>>>> + * @param ids
>>>>>>> + * IDs array to retrieve specific statistics. Must not be NULL.
>>>>>>> + * @param values
>>>>>>> + * A pointer to a table to be filled with device statistics values.
>>>>>>> + * Must not be NULL.
>>>>>>> + * @param n
>>>>>>> + * Element count in @p ids and @p values.
>>>>>>> + *
>>>>>>> + * @return
>>>>>>> + * - A number of filled in stats.
>>>>>>> + * - A negative value on error.
>>>>>>> + */
>>>>>>> typedef int (*eth_xstats_get_by_id_t)(struct rte_eth_dev *dev,
>>>>>>> const uint64_t *ids,
>>>>>>> uint64_t *values,
>>>>>>> unsigned int n);
>>>>>>> -/**< @internal Get extended stats of an Ethernet device. */
>>>>>>>
>>>>>>> /**
>>>>>>> * @internal
>>>>>>> @@ -218,10 +235,31 @@ typedef int (*eth_xstats_get_names_t)(struct rte_eth_dev *dev,
>>>>>>> struct rte_eth_xstat_name *xstats_names, unsigned int size);
>>>>>>> /**< @internal Get names of extended stats of an Ethernet device. */
>>>>>>>
>>>>>>> +/**
>>>>>>> + * @internal
>>>>>>> + * Get names of extended stats of an Ethernet device.
>>>>>>> + * For name count, set @p xstats_names and @p ids to NULL.
>>>>>>
>>>>>> Why limiting this behavior to 'xstats_get_names_by_id'?
>>>>>>
>>>>>> Internally 'xstats_get_names_by_id' is used to get the count, but I think this
>>>>>> is not intentionally selected, just one of the xstats_*_by_id dev_ops used.
>>>>>>
>>>>>> I think it is confusing to have this support for one of the '_by_id' dev_ops but
>>>>>> not for other. Why not require both to support returning 'count'?
>>>>>
>>>>> Simply because it is dead code. There is no point to require
>>>>> from driver to have dead code.
>>>>>
>>>>
>>>> Let me step back a little, both ethdev APIs can be used to return xstats count
>>>> by providing 'values/names' & 'ids' pointers as NULL and 'size' as 0:
>>>> 'rte_eth_xstats_get_names_by_id()'
>>>> 'rte_eth_xstats_get_by_id()'
>>>>
>>>> But internally both APIs use 'xstats_get_names_by_id' dev_ops to get the count,
>>>> as said above I believe this selection is done unintentionally.
>>>>
>>>>
>>>> I am for below two options:
>>>>
>>>> a) Internally use 'xstats_get_names' || 'xstats_get' dev_ops to get the xstats
>>>> count, and doesn't support getting xstats count for both '_by_id' dev_ops, this
>>>> simplifies driver code. As far as I remember I suggested this before, still I
>>>> prefer this one.
>>>>
>>>> b) If we will support getting xstats count from '_by_id' dev_ops, I think both
>>>> should support it, to not make it more complex to figure out which one support
>>>> what. As sample both 'xstats_get_names' and 'xstats_get' supports getting xstats
>>>> count, not just one.
>>>>
>>>
>>> In (b) do you suggest to change ethdev to use xstats_get_by_id
>>> driver op if users asks for a number of xstats using
>>> rte_eth_xstats_get_by_id()? It will complicate ethdev and
>>> will complicate drivers. Just for the symmetry?
>>>
>>
>> Not just for symmetry, but simplify the logic. Both dev_ops are very similar and
>
> I'm sorry, but could you point of which logic you'd
> like to simply. Less requirements on driver ops
> means less code required inside.
>
>> they are having different behavior with same parameters is confusing.
>
> Ah, logic from PMD maintainer point of view. Does it
> really worse to require extra code inside because of it?
>
>> If you want to simplify the drivers why not go with option (a)? Option (a) also
>> doesn't change external API, and has only minor change in the ethdev layer.
>
> Is two extra patches in v6 (discussed below) a step
> towards (a)?
>
I am not sure of it, for (a) ethdev layer will handle getting all stats or
getting count using 'xstats_get_names' || 'xstats_get', and '*_by_id()' dev_ops
will become simpler since they won't accept NULL 'ids' & 'values'.
Also when dev_ops merged, it forces PMDs to implement the getting by ids, but
now it is covered by ethdev layer for the PMDs that doesn't implement '_by_id()'.
>>> The patch does not change external API, does not change etcdev
>>> bahaviour. It just clarify requirements on driver ops to
>>> allow to check less in all drivers and support less cases
>>> in all drivers.
>>>
>>
>> It is not clarifying the requirements of dev_ops, but changing it. Previously
>> there was nothing saying only one of the '_by_id' dev_ops should support
>> returning element count.
>
> I say "clarifying" since I adjust it a real source of
> truth for internals - implementation, usage of these
> callback by ethdev layer.
>
> Yes, I agree that it changes documentation.
>
>>
>>> If we make a one more step back, frankly speaking I think we
>>> have too many functions to retrieve statistics. I can
>>> understand from ethdev API point of view taking API stability
>>> into account etc. But why do we have so many complicated
>>> driver callbacks?
>>>> First of all I'd like to do one more cleanup:
>>> change eth_xstats_get_names_by_id_t prototype to
>>> have ids before xstats_names.
>>> I.e. eth_xstats_get_by_id_t(dev, ids, values, size)
>>> eth_xstats_get_names_by_id_t(dev, ids, names, size)
>>>
>>
>> +1
>
> See patch 3/4 in v6
>
>>
>>> Second, merge eth_xstats_get_names_t and eth_xstats_get_names_by_id_t
>>> callbacks to keep
>>> name of the first, but prototype from the second.
>>> The reason is equal functionality if ids==NULL,
>>> shorter name of the first and optional ids (i.e. no
>>> reason to mention optional parameter in name).
>>> Drivers which do not implement by_id_t,
>>> but implement eth_xstats_get_names_t, will simply
>>> return ENOTSUP if ids!=NULL.
>>>
>>
>> No objection, _by_id() version is already superset of the other.
>
> See patch 4/4 in v6
>
>>
>>> The case of values ops is more complicated,
>>> however since:
>>>
>>> 2834 * There is an assumption that 'xstat_names' and 'xstats' arrays
>>> are matched
>>> 2835 * by array index:
>>> 2836 * xstats_names[i].name => xstats[i].value
>>> 2837 *
>>> 2838 * And the array index is same with id field of 'struct rte_eth_xstat':
>>> 2839 * xstats[i].id == i
>>> 2840 *
>>> 2841 * This assumption makes key-value pair matching less flexible but
>>> simpler.
>>>
>>> we can switch to eth_xstats_get_by_id_t only callback as
>>> well and fill in stats->id equal to index on ethdev layer.
>>
>> When ids != NULL, the index from 'ids' can be used, isn't it.
>
> Yes, of course, but above documentation is for API without IDs.
>
>>
>>> However, it will require extra buffer for
>>> uint64_t *values and copying in the rte_eth_xstats_get()
>>> implementation. So, I doubt in this case.
>>>
>>
>> Overall merging xstats _by_id APIs doesn't look bad idea, but since it will
>> require change in applications, I am not really sure if benefit worth the
>> trouble it brings to users.
>
> Yes, I agree. I'm not going to change external API.
>
>>> In fact, it is sad that we still do not move forward
>>> in accordance with Thomas presentation made 2 years ago.
>>>
>>
>> In my experience things don't move forward without proper plan (who, what, when).
>>
>
> +1
>