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 DA3B843A1E; Wed, 31 Jan 2024 15:38:02 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 940C84026B; Wed, 31 Jan 2024 15:38:02 +0100 (CET) Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.93]) by mails.dpdk.org (Postfix) with ESMTP id BF70840269 for ; Wed, 31 Jan 2024 15:38:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1706711880; x=1738247880; h=date:from:to:cc:subject:message-id:references: content-transfer-encoding:in-reply-to:mime-version; bh=rYpfx1+8eukBLsOpmKUj0hr2Vldbhq72v0a9QGcPrms=; b=dMUCQAIZDGgsIrQehypm9ZT+kMEvqiyqTCB9EXs4Szr1uJ+igk+mS2fM VJBSjuPfIu7dzTMihCa0+SURbCeBfh4KL/j8lSLZXjLt4xiPhml6sW9q9 pEMPWGqGz7hCPoOh8fd5NjdfivSCgV8CNP3aoB7Nd0mSbNN3UQ2uz5ruv nJA5doF5lqeoKTuKwv59+gQEMNMygfbYh5mBk7j7cGtArRcN8IA9VgBXp 6pJfMFkigXArKLOKRu4BN4He3z7QEyEnoRRxgv+99Z4pOxIZQzy5CibYy c2de4TAl8MhhQvTPujL/etb2d+Ib1qsE0ibMzhyv+kAN2CGRkkxVQWJ3D g==; X-IronPort-AV: E=McAfee;i="6600,9927,10969"; a="400753891" X-IronPort-AV: E=Sophos;i="6.05,231,1701158400"; d="scan'208";a="400753891" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Jan 2024 06:37:59 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10969"; a="911803068" X-IronPort-AV: E=Sophos;i="6.05,231,1701158400"; d="scan'208";a="911803068" Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by orsmga004.jf.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 31 Jan 2024 06:37:59 -0800 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Wed, 31 Jan 2024 06:37:59 -0800 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend Transport; Wed, 31 Jan 2024 06:37:59 -0800 Received: from NAM04-MW2-obe.outbound.protection.outlook.com (104.47.73.169) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Wed, 31 Jan 2024 06:37:59 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Kx/KgY8uLmUXvpq0jqWIus6GVxWYhhK0cWBC+kZ1+WlfBhPIAs/BIrujhhaYAuPdUNplm5kkBRNhWlLVNjvvpQ3rSHNSkMk4PC20V4z/21I7zHaKCvjuk9eZ7k76HrFYz1S3GmlC9Yr9hrp2wDaIUGoVoL4We44KKTv3N5PfU+qfwrPVdduzPqtcKtY3sKsFP4QOFYTgVvV2YmCvbq7IP4mrrpLNXtax91yyaTn5b78p1ZOm6VGb1QOILNIXX22eHL71LbKpKrFZNWTa5QvG4MJ7iAxrHwCbVHn2SmbW7piTun15AHMeBz50mkl6DZuLWEkyOk8xx10IErevTAtnTg== 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=rUUnNXlBHizJ/VKg59mrrhugLOSqQsSyS4VxsNT+kt0=; b=nQn8XIyl0/yDBXXzIKdFocL4SRUrz+Zfp/bC3xb27fVofGhmX/LaPIb1BikMuuZxarVO7t3cXwt7uYRBWaYA5DT/npiE/CfXQLkF3s4VA8RhKjmaZGpiTLlilmxSVswSQYZHDqC+XDlSpw5F0AZTRXPMxEgZE16C0lK8jv8EGnHUciRKfRqzzXnefxsBEl/y2mcoeCJj9P2QKsfHf2f1y/F5iTqLSzzmED76Qel+CCdHHLeca0Jr2UjNfHGb3WOjNLog9jsx6XpCroxVmBMH0xMqS7kzaKn5qClekKPUfvosT8S2FxSA8NH/cIIIy6DAr5NDtbXoRDdNJ6V2NOTJ6w== 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 CH3PR11MB7841.namprd11.prod.outlook.com (2603:10b6:610:121::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7249.24; Wed, 31 Jan 2024 14:37:54 +0000 Received: from DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::df88:b743:97f8:516c]) by DS0PR11MB7309.namprd11.prod.outlook.com ([fe80::df88:b743:97f8:516c%5]) with mapi id 15.20.7249.017; Wed, 31 Jan 2024 14:37:54 +0000 Date: Wed, 31 Jan 2024 14:37:47 +0000 From: Bruce Richardson To: Mattias =?iso-8859-1?Q?R=F6nnblom?= CC: , , , , , , , Subject: Re: [PATCH v2 04/11] eventdev: cleanup doxygen comments on info structure Message-ID: References: <20240118134557.73172-1-bruce.richardson@intel.com> <20240119174346.108905-1-bruce.richardson@intel.com> <20240119174346.108905-5-bruce.richardson@intel.com> <65d09512-f184-4ac4-a513-e5820754889e@lysator.liu.se> <26f7d4b7-d46f-461b-a891-7a32d14f4b21@lysator.liu.se> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <26f7d4b7-d46f-461b-a891-7a32d14f4b21@lysator.liu.se> X-ClientProxiedBy: DU7PR01CA0003.eurprd01.prod.exchangelabs.com (2603:10a6:10:50f::17) To DS0PR11MB7309.namprd11.prod.outlook.com (2603:10b6:8:13e::17) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7309:EE_|CH3PR11MB7841:EE_ X-MS-Office365-Filtering-Correlation-Id: 0ad9e1b7-24ff-4b76-3ab1-08dc226a3582 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 2pNRtDgpt3/NeoXS/Rwi7aYCBYwtMdYVyOI3thT1z9NeavixvyQjD8mvv0bneXun9CgrCf9qBnOmYiHhIfeSIdvKRB0m+UOMUnHQ6WYeVnsHfqxVttmg6SLFVUX+SqYtyFcrJVXhJMVx2vIzeFOh1N61cLWgi7Q2KPl8Q2gNp2KlkfMGEST/ZaXO5C7dZncS1TwoF7FrOvF14iP7vnbH1os93d1mHUJbtXWj8tXnCMNIR1FmwxXylY1SOGTT6DHkHPpAXE9IivOhGi2dObM82YbQOk93rnh5KNHya6Z36nYUQ1FGCidq//yVMtTVib9dq2/7iDh36d/eFH6lXM0sqYAF5WiHsX2+IOC6XB0H3kYv5m47+jhDsbHb2TUoyijVONkLqZZVgn6+zbN2ZdZPFQBNFxWUU3WHanaRccRFBgmYX/9ZhQrhYnYbkhKDNHRBAIo+c+0Yqsu2kicF7DbHzTJcJKGvj9lSFP4pEztrx1XN8fw5+68fdKU+Ym8c/tIVTHK33yYM0225wRzWCD2KynuBqwAyVWCpAR0PMiWyfHDjsh0LhVC1I3UTlz02PNnO 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:(13230031)(39860400002)(376002)(136003)(366004)(346002)(396003)(230922051799003)(64100799003)(1800799012)(451199024)(186009)(44832011)(8676002)(4326008)(8936002)(2906002)(5660300002)(86362001)(66556008)(66946007)(66476007)(6916009)(316002)(296002)(38100700002)(53546011)(82960400001)(478600001)(6512007)(6666004)(6486002)(83380400001)(6506007)(107886003)(26005)(66574015)(41300700001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?Ol7zWpBFF2g0qNCr6czX49q4aWKxoFrTIKLF5/JruRZa9UD5XJ+UmG22ai?= =?iso-8859-1?Q?yd6X32k7pLK9kd3AtUvJ+J1obup3bfTgEyhH3dENLybq7cLIFnSPXS92S7?= =?iso-8859-1?Q?uVLzyXxdIcl7MFIux/cRCh+XV1oK8Gu6qucrPXswlmg6izv/pA4mx5slbI?= =?iso-8859-1?Q?oT9qbhatVjHbV7TEC7GHbokhao8j+RUN5kk4UtY2FYm1IeyuNI6O60a0d4?= =?iso-8859-1?Q?1qS6iXbM+q7BvmO+dkvwGq/w7FO3eg6kpBbmogCkNXzpTDRIBU9Mh1xHLj?= =?iso-8859-1?Q?4qLRRIo61hiAtwNAmDIGvuYAODmDhLGpJncCv2fJtn2fOIe0ymo6vY+qTK?= =?iso-8859-1?Q?8JZ79HLTUs3eW3T1h3vwdvlWeW/kNjMHNhqk5yYOPhSMa2qSSDZilTQxcc?= =?iso-8859-1?Q?daloDNQbBxY5QgOUg+0Cwg2twrkFsqf3f3rpjSAVXCO1k0dOfThzbdJ5Sq?= =?iso-8859-1?Q?PA+HvTZsxUphOzrRABBrAaoLV9WcWjE0kd/ubu4UZhEmTXNI9CZSrimsXT?= =?iso-8859-1?Q?PW4gCUs6II5GYUgT6INLpvY+xEmt++hw+OTtAJ633XbAdsuwh0+K9ejmmc?= =?iso-8859-1?Q?3mBlP2yKdHgDotSbcTrpFUNrhxamQTW1SZjN5E3lW4e0nevMFrXoz5ZbJh?= =?iso-8859-1?Q?KrPEbFyBXrEoymBjIw8yEVtil3+pOhRQdfiD2fkDQeELOveOg6o85gwwZ4?= =?iso-8859-1?Q?FSr0Qw7R2/vlb4dhmzxrzLT1T5auRj9gPZ1A3iZfl/OAWniOo7wr1Kmop1?= =?iso-8859-1?Q?c9ObQWAbvbMynAY9fnu+bS6AXClvf6Z8uruGrRbC1CCxEEZ75IMHdpPdcC?= =?iso-8859-1?Q?url6K/RfOhTAOTO3K5qMBpilGxkKNVjCK2y0rgxEMNJDnOzm38YeRl2KGG?= =?iso-8859-1?Q?wDdC0oqpF5jFIHGDrqHK3CZ2jBeFBOgQej7Ig5vF9Qz2+ehbZN7H60ayF6?= =?iso-8859-1?Q?/J75nMVPGN7StHJH3qGU9NbreiVTRxRMAYbUa5Kk4F5ISWYnzYg9bHZhRd?= =?iso-8859-1?Q?UFd/ktN0s6qlE7PAfyi3AY+jZPjhwyIEkMZyKkt98cvBV1RnzTtgTn9794?= =?iso-8859-1?Q?YqEsqrIsJZC9zdDUrsRZb0T4rSXFYrRFUsIKYSEAWLfUp1hVj8MdeUo1ju?= =?iso-8859-1?Q?wSo9J4jwOXmGJaYerEtq5qOUis9i1zyX8d/v2thoxyn2SxamrPlPq518oT?= =?iso-8859-1?Q?7rW0TT0Kvye17P51nL/NKjjdoUsLq/MWWzNO/bLYrKblGnruTybSXyonib?= =?iso-8859-1?Q?HaB/Cq+LY27yFVzzu3mk4hzx8BqWIENrfHCMg9iOZWWXtNQmseDwpbeEQ6?= =?iso-8859-1?Q?SS+Hv6fINltYG72U/NINlf5qSu+v9v08lXDkD9MRD44NlVpTbQKNSPggvk?= =?iso-8859-1?Q?wnqscyWQwGaQXZdJS7DzaRLFKu5ap819vi8Iomr+EA8eB9+dtLlLXwRiSs?= =?iso-8859-1?Q?JF8iyS3dmt7ft2AJo+em89rSvOOpFuwkP/CbQqLzh1KwVz8PjuBhK8E9Tt?= =?iso-8859-1?Q?ekkxK3nSEAYLoGvFC2C3AYz+p3NkoWJeppGt7nXXSXZESS4GitVfcvzy7P?= =?iso-8859-1?Q?aqRuRXwgpqQLXIflOX6q304wVhOmHbZoTYY93OigsKM9ux1wxMsYyVPRoq?= =?iso-8859-1?Q?01ZH+5B5A+eqP0axNtg53VYHn8FsNV322AXA0qAU7dobFOOcPi1qZHgA?= =?iso-8859-1?Q?=3D=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: 0ad9e1b7-24ff-4b76-3ab1-08dc226a3582 X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7309.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jan 2024 14:37:54.1542 (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: xJRQbtx0/OPExU/KT3WevtOah1ayJnP9jND9kyRbgaWY0U5cSVK+RjoUhtqUYjAhrE/Qo6fBpZ0sy6+V20ME6sQIavde4ilPFWCt+A0fx+Q= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR11MB7841 X-OriginatorOrg: intel.com 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 Wed, Jan 24, 2024 at 12:51:03PM +0100, Mattias Rönnblom wrote: > On 2024-01-23 10:43, Bruce Richardson wrote: > > On Tue, Jan 23, 2024 at 10:35:02AM +0100, Mattias Rönnblom wrote: > > > On 2024-01-19 18:43, Bruce Richardson wrote: > > > > Some small rewording changes to the doxygen comments on struct > > > > rte_event_dev_info. > > > > > > > > Signed-off-by: Bruce Richardson > > > > --- > > > > lib/eventdev/rte_eventdev.h | 46 ++++++++++++++++++++----------------- > > > > 1 file changed, 25 insertions(+), 21 deletions(-) > > > > > > > > diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h > > > > index 57a2791946..872f241df2 100644 > > > > --- a/lib/eventdev/rte_eventdev.h > > > > +++ b/lib/eventdev/rte_eventdev.h > > > > @@ -482,54 +482,58 @@ struct rte_event_dev_info { > > > > const char *driver_name; /**< Event driver name */ > > > > struct rte_device *dev; /**< Device information */ > > > > uint32_t min_dequeue_timeout_ns; > > > > - /**< Minimum supported global dequeue timeout(ns) by this device */ > > > > + /**< Minimum global dequeue timeout(ns) supported by this device */ > > > > > > Are we missing a bunch of "." here and in the other fields? > > > > > > > uint32_t max_dequeue_timeout_ns; > > > > - /**< Maximum supported global dequeue timeout(ns) by this device */ > > > > + /**< Maximum global dequeue timeout(ns) supported by this device */ > > > > uint32_t dequeue_timeout_ns; > > > > /**< Configured global dequeue timeout(ns) for this device */ > > > > uint8_t max_event_queues; > > > > - /**< Maximum event_queues supported by this device */ > > > > + /**< Maximum event queues supported by this device */ > > > > uint32_t max_event_queue_flows; > > > > - /**< Maximum supported flows in an event queue by this device*/ > > > > + /**< Maximum number of flows within an event queue supported by this device*/ > > > > uint8_t max_event_queue_priority_levels; > > > > /**< Maximum number of event queue priority levels by this device. > > > > - * Valid when the device has RTE_EVENT_DEV_CAP_QUEUE_QOS capability > > > > + * Valid when the device has RTE_EVENT_DEV_CAP_QUEUE_QOS capability. > > > > + * The priority levels are evenly distributed between > > > > + * @ref RTE_EVENT_DEV_PRIORITY_HIGHEST and @ref RTE_EVENT_DEV_PRIORITY_LOWEST. > > > > > > This is a change of the API, in the sense it's defining something previously > > > left undefined? > > > > > > > Well, undefined is pretty useless for app writers, no? > > However, agreed that the range between HIGHEST and LOWEST is an assumption > > on my part, chosen because it matches what happens to the event priorities > > which are documented in event struct as "The implementation shall normalize > > the requested priority to supported priority value" - which, while better > > than nothing, does technically leave the details of how normalization > > occurs up to the implementation. > > > > > If you need 6 different priority levels in an app, how do you go about > > > making sure you find the correct (distinct) Eventdev levels on any event > > > device supporting >= 6 levels? > > > > > > #define NUM_MY_LEVELS 6 > > > > > > #define MY_LEVEL_TO_EVENTDEV_LEVEL(my_level) (((my_level) * > > > (RTE_EVENT_DEV_PRIORITY_HIGHEST-RTE_EVENT_DEV_PRIORTY_LOWEST) / > > > NUM_MY_LEVELS) > > > > > > This way? One would worry a bit exactly what "evenly" means, in terms of > > > rounding errors. If you have an event device with 255 priority levels of > > > (say) 256 levels available in the API, which two levels are the same > > > priority? > > > > Yes, round etc. will be an issue in cases of non-powers-of 2. > > However, I think we do need to clarify this behaviour, so I'm open to > > alternative suggestions as to how update this. > > > > In retrospect, maybe it would have been better to just express the number of > priority levels an event device supported, only allow [0, max_levels - 1] in > the prio field, and leave it to the app to do the conversion/normalization. > Yes, in many ways that would be better. > Maybe a new helper macro would at least suggest to the PMD > driver implementer and the application designer how this normalization > should work. Something like the above, but where NUM_MY_LEVELS is an input > parameter. Would result in an integer division though, so shouldn't be used > in the fast path. I think it's actually ok now, having the drivers do the work, since each driver can choose optimal method. For those having power-of-2 number of priorities, just a shift op works best. The key thing for the documentation here, to my mind, is to make it clear that though the number of priorities is N, you still specify the relative priorities in the range of 0-255. This is documented in the queue configuration, so, while we could leave it unmentionned here, I think for clarity it should be called out. I'm going to reword slightly as: * The implementation shall normalize priority values specified between * @ref RTE_EVENT_DEV_PRIORITY_HIGHEST and @ref RTE_EVENT_DEV_PRIORITY_LOWEST * to map them internally to this range of priorities. * * @see rte_event_queue_conf.priority This way the wording in the two places is similar. /Bruce