DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Mattias Rönnblom" <hofors@lysator.liu.se>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: dev@dpdk.org, jerinj@marvell.com, mattias.ronnblom@ericsson.com,
	abdullah.sevincer@intel.com, sachin.saxena@oss.nxp.com,
	hemant.agrawal@nxp.com, pbhagavatula@marvell.com,
	pravin.pathak@intel.com
Subject: Re: [PATCH v2 04/11] eventdev: cleanup doxygen comments on info structure
Date: Fri, 2 Feb 2024 10:24:54 +0100	[thread overview]
Message-ID: <839761ae-ee75-4a77-8f00-f0848ff638a4@lysator.liu.se> (raw)
In-Reply-To: <ZbpbOyUc9LviwiDL@bricha3-MOBL.ger.corp.intel.com>

On 2024-01-31 15:37, Bruce Richardson wrote:
> 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 <bruce.richardson@intel.com>
>>>>> ---
>>>>>     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 <rte_eventdev.h> 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.
> 

I had an application-usable macro in mind, not a macro for PMDs. Showing 
how app-level priority levels should map to Eventdev API-level priority 
levels would, by implication, show how event device should do the 
Eventdev API priority -> PMD level priority compression.

The event device has exactly zero freedom in choosing how to translate 
Eventdev API-level priorities to its internal priorities, or risk not 
differentiating between app-level priority levels. If an event device 
supports 128 levels, is RTE_EVENT_DEV_PRIORITY_NORMAL and 
RTE_EVENT_DEV_PRIORITY_NORMAL-1 the same PMD-level priority or not? I 
would *guess* the same, but that just an assumption, and not something 
that follows from "normalize", I think.

Anyway, this is not a problem this patch set necessarily needs to solve.

> 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

  reply	other threads:[~2024-02-02  9:24 UTC|newest]

Thread overview: 123+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-18 13:45 [PATCH v1 0/7] improve eventdev API specification/documentation Bruce Richardson
2024-01-18 13:45 ` [PATCH v1 1/7] eventdev: improve doxygen introduction text Bruce Richardson
2024-01-18 13:45 ` [PATCH v1 2/7] eventdev: move text on driver internals to proper section Bruce Richardson
2024-01-18 13:45 ` [PATCH v1 3/7] eventdev: update documentation on device capability flags Bruce Richardson
2024-01-18 13:45 ` [PATCH v1 4/7] eventdev: cleanup doxygen comments on info structure Bruce Richardson
2024-01-18 13:49   ` Bruce Richardson
2024-01-18 13:45 ` [PATCH v1 5/7] eventdev: improve function documentation for query fns Bruce Richardson
2024-01-18 13:45 ` [PATCH v1 6/7] eventdev: improve doxygen comments on configure struct Bruce Richardson
2024-01-18 13:45 ` [PATCH v1 7/7] eventdev: fix documentation for counting single-link ports Bruce Richardson
2024-01-19 17:43 ` [PATCH v2 00/11] improve eventdev API specification/documentation Bruce Richardson
2024-01-19 17:43   ` [PATCH v2 01/11] eventdev: improve doxygen introduction text Bruce Richardson
2024-01-23  8:57     ` Mattias Rönnblom
2024-01-23  9:06       ` Bruce Richardson
2024-01-24 11:37         ` Mattias Rönnblom
2024-01-31 13:45       ` Bruce Richardson
2024-01-19 17:43   ` [PATCH v2 02/11] eventdev: move text on driver internals to proper section Bruce Richardson
2024-01-19 17:43   ` [PATCH v2 03/11] eventdev: update documentation on device capability flags Bruce Richardson
2024-01-23  9:18     ` Mattias Rönnblom
2024-01-23  9:34       ` Bruce Richardson
2024-01-31 14:09       ` Bruce Richardson
2024-02-02  8:58         ` Mattias Rönnblom
2024-02-02 11:20           ` Bruce Richardson
2024-01-19 17:43   ` [PATCH v2 04/11] eventdev: cleanup doxygen comments on info structure Bruce Richardson
2024-01-23  9:35     ` Mattias Rönnblom
2024-01-23  9:43       ` Bruce Richardson
2024-01-24 11:51         ` Mattias Rönnblom
2024-01-31 14:37           ` Bruce Richardson
2024-02-02  9:24             ` Mattias Rönnblom [this message]
2024-02-02 10:30               ` Bruce Richardson
2024-01-19 17:43   ` [PATCH v2 05/11] eventdev: improve function documentation for query fns Bruce Richardson
2024-01-23  9:40     ` Mattias Rönnblom
2024-01-19 17:43   ` [PATCH v2 06/11] eventdev: improve doxygen comments on configure struct Bruce Richardson
2024-01-23  9:46     ` Mattias Rönnblom
2024-01-31 16:15       ` Bruce Richardson
2024-01-19 17:43   ` [PATCH v2 07/11] eventdev: fix documentation for counting single-link ports Bruce Richardson
2024-01-23  9:48     ` Mattias Rönnblom
2024-01-23  9:56       ` Bruce Richardson
2024-01-31 16:18         ` Bruce Richardson
2024-01-19 17:43   ` [PATCH v2 08/11] eventdev: improve doxygen comments on config fns Bruce Richardson
2024-01-23 10:00     ` Mattias Rönnblom
2024-01-23 10:07       ` Bruce Richardson
2024-01-19 17:43   ` [PATCH v2 09/11] eventdev: improve doxygen comments for control APIs Bruce Richardson
2024-01-23 10:10     ` Mattias Rönnblom
2024-01-19 17:43   ` [PATCH v2 10/11] eventdev: RFC clarify comments on scheduling types Bruce Richardson
2024-01-23 16:19     ` Mattias Rönnblom
2024-01-24 11:21       ` Bruce Richardson
2024-01-31 17:54       ` Bruce Richardson
2024-01-19 17:43   ` [PATCH v2 11/11] eventdev: RFC clarify docs on event object fields Bruce Richardson
2024-01-24 11:34     ` Mattias Rönnblom
2024-02-01 16:59       ` Bruce Richardson
2024-02-02  9:38         ` Mattias Rönnblom
2024-02-02 11:33           ` Bruce Richardson
2024-02-02 12:02             ` Bruce Richardson
2024-02-01 17:02       ` Bruce Richardson
2024-02-02  9:14         ` Bruce Richardson
2024-02-02  9:22         ` Jerin Jacob
2024-02-02  9:36           ` Bruce Richardson
2024-02-02  9:45         ` Mattias Rönnblom
2024-02-02 10:32           ` Bruce Richardson
2024-02-01  9:35     ` Bruce Richardson
2024-02-01 15:00       ` Jerin Jacob
2024-02-01 15:24         ` Bruce Richardson
2024-02-01 16:20           ` Jerin Jacob
2024-02-02 12:39   ` [PATCH v3 00/11] improve eventdev API specification/documentation Bruce Richardson
2024-02-02 12:39     ` [PATCH v3 01/11] eventdev: improve doxygen introduction text Bruce Richardson
2024-02-07 10:14       ` Jerin Jacob
2024-02-08  9:50         ` Mattias Rönnblom
2024-02-09  8:43           ` Jerin Jacob
2024-02-10  7:24             ` Mattias Rönnblom
2024-02-20 16:28               ` Bruce Richardson
2024-02-20 16:33         ` Bruce Richardson
2024-02-02 12:39     ` [PATCH v3 02/11] eventdev: move text on driver internals to proper section Bruce Richardson
2024-02-02 12:39     ` [PATCH v3 03/11] eventdev: update documentation on device capability flags Bruce Richardson
2024-02-07 10:30       ` Jerin Jacob
2024-02-20 16:42         ` Bruce Richardson
2024-02-02 12:39     ` [PATCH v3 04/11] eventdev: cleanup doxygen comments on info structure Bruce Richardson
2024-02-02 12:39     ` [PATCH v3 05/11] eventdev: improve function documentation for query fns Bruce Richardson
2024-02-02 12:39     ` [PATCH v3 06/11] eventdev: improve doxygen comments on configure struct Bruce Richardson
2024-02-02 12:39     ` [PATCH v3 07/11] eventdev: improve doxygen comments on config fns Bruce Richardson
2024-02-02 12:39     ` [PATCH v3 08/11] eventdev: improve doxygen comments for control APIs Bruce Richardson
2024-02-02 12:39     ` [PATCH v3 09/11] eventdev: improve comments on scheduling types Bruce Richardson
2024-02-08  9:18       ` Jerin Jacob
2024-02-08 10:04         ` Mattias Rönnblom
2024-02-20 17:23           ` Bruce Richardson
2024-02-02 12:39     ` [PATCH v3 10/11] eventdev: clarify docs on event object fields and op types Bruce Richardson
2024-02-09  9:14       ` Jerin Jacob
2024-02-20 17:39         ` Bruce Richardson
2024-02-21  9:31           ` Jerin Jacob
2024-02-21 10:28             ` Bruce Richardson
2024-02-20 17:50         ` Bruce Richardson
2024-02-20 18:03         ` Bruce Richardson
2024-02-02 12:39     ` [PATCH v3 11/11] eventdev: drop comment for anon union from doxygen Bruce Richardson
2024-02-21 10:32   ` [PATCH v4 00/12] improve eventdev API specification/documentation Bruce Richardson
2024-02-21 10:32     ` [PATCH v4 01/12] eventdev: improve doxygen introduction text Bruce Richardson
2024-02-26  4:51       ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-02-26  9:59         ` Bruce Richardson
2024-02-29 16:13           ` Jerin Jacob
2024-02-21 10:32     ` [PATCH v4 02/12] eventdev: move text on driver internals to proper section Bruce Richardson
2024-02-26  5:01       ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-02-21 10:32     ` [PATCH v4 03/12] eventdev: update documentation on device capability flags Bruce Richardson
2024-02-26  5:07       ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-02-21 10:32     ` [PATCH v4 04/12] eventdev: cleanup doxygen comments on info structure Bruce Richardson
2024-02-26  5:18       ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-02-21 10:32     ` [PATCH v4 05/12] eventdev: improve function documentation for query fns Bruce Richardson
2024-02-26  5:18       ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-02-21 10:32     ` [PATCH v4 06/12] eventdev: improve doxygen comments on configure struct Bruce Richardson
2024-02-26  6:36       ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-02-21 10:32     ` [PATCH v4 07/12] eventdev: improve doxygen comments on config fns Bruce Richardson
2024-02-26  6:43       ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-02-26  6:44         ` Pavan Nikhilesh Bhagavatula
2024-02-21 10:32     ` [PATCH v4 08/12] eventdev: improve doxygen comments for control APIs Bruce Richardson
2024-02-26  6:44       ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-02-21 10:32     ` [PATCH v4 09/12] eventdev: improve comments on scheduling types Bruce Richardson
2024-02-26  6:49       ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-02-21 10:32     ` [PATCH v4 10/12] eventdev: clarify docs on event object fields and op types Bruce Richardson
2024-02-26  6:52       ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-02-21 10:32     ` [PATCH v4 11/12] eventdev: drop comment for anon union from doxygen Bruce Richardson
2024-02-26  6:52       ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-02-21 10:32     ` [PATCH v4 12/12] eventdev: fix doxygen processing of event vector struct Bruce Richardson
2024-02-26  6:53       ` [EXT] " Pavan Nikhilesh Bhagavatula
2024-03-04 15:35       ` Thomas Monjalon
2024-03-04 15:49         ` Bruce Richardson
2024-02-23 12:36     ` [PATCH v4 00/12] improve eventdev API specification/documentation Jerin Jacob

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=839761ae-ee75-4a77-8f00-f0848ff638a4@lysator.liu.se \
    --to=hofors@lysator.liu.se \
    --cc=abdullah.sevincer@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=hemant.agrawal@nxp.com \
    --cc=jerinj@marvell.com \
    --cc=mattias.ronnblom@ericsson.com \
    --cc=pbhagavatula@marvell.com \
    --cc=pravin.pathak@intel.com \
    --cc=sachin.saxena@oss.nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).