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.richard...@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.
/Bruce
