[24.03,1/8] eventdev: add capability flags for supported sched types
Checks
Commit Message
Not all eventdev's support all scheduling types, for example, some may
only support atomic scheduling or others only support ordered
scheduling. There is currently no clear indication for each driver what
sched types it supports, so add capability flags to be indicated on
return from rte_event_dev_info_get() API.
Similarly add the possible scheduling types to the capabilities table in
the docs.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
doc/guides/eventdevs/features/default.ini | 3 +++
lib/eventdev/rte_eventdev.h | 21 +++++++++++++++++++++
2 files changed, 24 insertions(+)
--
2.39.2
Comments
On Mon, Nov 20, 2023 at 11:08 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> Not all eventdev's support all scheduling types, for example, some may
> only support atomic scheduling or others only support ordered
> scheduling. There is currently no clear indication for each driver what
> sched types it supports, so add capability flags to be indicated on
> return from rte_event_dev_info_get() API.
>
> Similarly add the possible scheduling types to the capabilities table in
> the docs.
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
> doc/guides/eventdevs/features/default.ini | 3 +++
> lib/eventdev/rte_eventdev.h | 21 +++++++++++++++++++++
> 2 files changed, 24 insertions(+)
>
> diff --git a/doc/guides/eventdevs/features/default.ini b/doc/guides/eventdevs/features/default.ini
> index e980ae134a..1cc4303fe5 100644
> --- a/doc/guides/eventdevs/features/default.ini
> +++ b/doc/guides/eventdevs/features/default.ini
> @@ -6,6 +6,9 @@
> ; the features table in the documentation.
> ;
> [Scheduling Features]
> +atomic_scheduling =
> +ordered_scheduling =
> +parallel_scheduling =
> queue_qos =
> event_qos =
> distributed_sched =
> diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
> index ec9b02455d..9109de157e 100644
> --- a/lib/eventdev/rte_eventdev.h
> +++ b/lib/eventdev/rte_eventdev.h
> @@ -326,6 +326,27 @@ struct rte_event;
> * than one.
> */
>
> +#define RTE_EVENT_DEV_CAP_ATOMIC (1ULL << 13)
> +/**< Event device is capable of atomic scheduling.
> + * When this flag is set, the application can configure queues with scheduling type
> + * atomic on this event device.
> + * @see RTE_SCHED_TYPE_ATOMIC
> + */
> +
> +#define RTE_EVENT_DEV_CAP_ORDERED (1ULL << 13)
> +/**< Event device is capable of ordered scheduling.
> + * When this flag is set, the application can configure queues with scheduling type
> + * ordered on this event device.
> + * @see RTE_SCHED_TYPE_ORDERED
> + */
> +
> +#define RTE_EVENT_DEV_CAP_PARALLEL (1ULL << 13)
> +/**< Event device is capable of parallel scheduling.
> + * When this flag is set, the application can configure queues with scheduling type
> + * parallel on this event device.
> + * @see RTE_SCHED_TYPE_PARALLEL
> + */
All the caps definition is 1ULL << 13. It should be unique per capa.
> /* Event device priority levels */
> #define RTE_EVENT_DEV_PRIORITY_HIGHEST 0
> /**< Highest priority expressed across eventdev subsystem
> --
> 2.39.2
>
On Mon, Nov 20, 2023 at 11:18:14PM +0530, Jerin Jacob wrote:
> On Mon, Nov 20, 2023 at 11:08 PM Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> >
> > Not all eventdev's support all scheduling types, for example, some may
> > only support atomic scheduling or others only support ordered
> > scheduling. There is currently no clear indication for each driver what
> > sched types it supports, so add capability flags to be indicated on
> > return from rte_event_dev_info_get() API.
> >
> > Similarly add the possible scheduling types to the capabilities table in
> > the docs.
> >
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > ---
> > doc/guides/eventdevs/features/default.ini | 3 +++
> > lib/eventdev/rte_eventdev.h | 21 +++++++++++++++++++++
> > 2 files changed, 24 insertions(+)
> >
> > diff --git a/doc/guides/eventdevs/features/default.ini b/doc/guides/eventdevs/features/default.ini
> > index e980ae134a..1cc4303fe5 100644
> > --- a/doc/guides/eventdevs/features/default.ini
> > +++ b/doc/guides/eventdevs/features/default.ini
> > @@ -6,6 +6,9 @@
> > ; the features table in the documentation.
> > ;
> > [Scheduling Features]
> > +atomic_scheduling =
> > +ordered_scheduling =
> > +parallel_scheduling =
> > queue_qos =
> > event_qos =
> > distributed_sched =
> > diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
> > index ec9b02455d..9109de157e 100644
> > --- a/lib/eventdev/rte_eventdev.h
> > +++ b/lib/eventdev/rte_eventdev.h
> > @@ -326,6 +326,27 @@ struct rte_event;
> > * than one.
> > */
> >
> > +#define RTE_EVENT_DEV_CAP_ATOMIC (1ULL << 13)
> > +/**< Event device is capable of atomic scheduling.
> > + * When this flag is set, the application can configure queues with scheduling type
> > + * atomic on this event device.
> > + * @see RTE_SCHED_TYPE_ATOMIC
> > + */
> > +
> > +#define RTE_EVENT_DEV_CAP_ORDERED (1ULL << 13)
> > +/**< Event device is capable of ordered scheduling.
> > + * When this flag is set, the application can configure queues with scheduling type
> > + * ordered on this event device.
> > + * @see RTE_SCHED_TYPE_ORDERED
> > + */
> > +
> > +#define RTE_EVENT_DEV_CAP_PARALLEL (1ULL << 13)
> > +/**< Event device is capable of parallel scheduling.
> > + * When this flag is set, the application can configure queues with scheduling type
> > + * parallel on this event device.
> > + * @see RTE_SCHED_TYPE_PARALLEL
> > + */
>
> All the caps definition is 1ULL << 13. It should be unique per capa.
>
Yep, good spot! Copy-paste error, naturally. :-(
Will fix in a v2.
/Bruce
On 2023-11-20 18:25, Bruce Richardson wrote:
> Not all eventdev's support all scheduling types, for example, some may
> only support atomic scheduling or others only support ordered
> scheduling. There is currently no clear indication for each driver what
> sched types it supports, so add capability flags to be indicated on
> return from rte_event_dev_info_get() API.
>
> Similarly add the possible scheduling types to the capabilities table in
> the docs.
>
Should we allow an event device to advertise
RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES, but not all of these?
With current wording of RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES prevents that,
but you should be able to allow for this without breaking backward
compatibility by tweaking the text from
"Event device is capable of enqueuing events of any type to any queue."
"Event device is capable of enqueuing events of any type advertised as
supported (e.g., by RTE_EVENT_DEV_CAP_ATOMIC)."
An event device that doesn't support ordered, but does support "all"
types seems reasonable to me, while an event device that does support
ordered on a per-event basis, but doesn't for queue-level configuration
does not.
If RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES is left unchanged, the user may ask
herself what "any" means (any supported in the API, or any supported by
the actual event device).
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
> doc/guides/eventdevs/features/default.ini | 3 +++
> lib/eventdev/rte_eventdev.h | 21 +++++++++++++++++++++
> 2 files changed, 24 insertions(+)
>
> diff --git a/doc/guides/eventdevs/features/default.ini b/doc/guides/eventdevs/features/default.ini
> index e980ae134a..1cc4303fe5 100644
> --- a/doc/guides/eventdevs/features/default.ini
> +++ b/doc/guides/eventdevs/features/default.ini
> @@ -6,6 +6,9 @@
> ; the features table in the documentation.
> ;
> [Scheduling Features]
> +atomic_scheduling =
> +ordered_scheduling =
> +parallel_scheduling =
> queue_qos =
> event_qos =
> distributed_sched =
> diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
> index ec9b02455d..9109de157e 100644
> --- a/lib/eventdev/rte_eventdev.h
> +++ b/lib/eventdev/rte_eventdev.h
> @@ -326,6 +326,27 @@ struct rte_event;
> * than one.
> */
>
> +#define RTE_EVENT_DEV_CAP_ATOMIC (1ULL << 13)
> +/**< Event device is capable of atomic scheduling.
> + * When this flag is set, the application can configure queues with scheduling type
> + * atomic on this event device.
> + * @see RTE_SCHED_TYPE_ATOMIC
> + */
> +
> +#define RTE_EVENT_DEV_CAP_ORDERED (1ULL << 13)
> +/**< Event device is capable of ordered scheduling.
> + * When this flag is set, the application can configure queues with scheduling type
> + * ordered on this event device.
> + * @see RTE_SCHED_TYPE_ORDERED
> + */
> +
> +#define RTE_EVENT_DEV_CAP_PARALLEL (1ULL << 13)
> +/**< Event device is capable of parallel scheduling.
> + * When this flag is set, the application can configure queues with scheduling type
> + * parallel on this event device.
> + * @see RTE_SCHED_TYPE_PARALLEL
> + */
> +
> /* Event device priority levels */
> #define RTE_EVENT_DEV_PRIORITY_HIGHEST 0
> /**< Highest priority expressed across eventdev subsystem
> --
> 2.39.2
>
On Tue, Nov 21, 2023 at 10:30:02AM +0100, Mattias Rönnblom wrote:
> On 2023-11-20 18:25, Bruce Richardson wrote:
> > Not all eventdev's support all scheduling types, for example, some may
> > only support atomic scheduling or others only support ordered
> > scheduling. There is currently no clear indication for each driver what
> > sched types it supports, so add capability flags to be indicated on
> > return from rte_event_dev_info_get() API.
> >
> > Similarly add the possible scheduling types to the capabilities table in
> > the docs.
> >
>
> Should we allow an event device to advertise
> RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES, but not all of these?
>
> With current wording of RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES prevents that, but
> you should be able to allow for this without breaking backward compatibility
> by tweaking the text from
>
> "Event device is capable of enqueuing events of any type to any queue."
>
> "Event device is capable of enqueuing events of any type advertised as
> supported (e.g., by RTE_EVENT_DEV_CAP_ATOMIC)."
>
> An event device that doesn't support ordered, but does support "all" types
> seems reasonable to me, while an event device that does support ordered on a
> per-event basis, but doesn't for queue-level configuration does not.
>
> If RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES is left unchanged, the user may ask
> herself what "any" means (any supported in the API, or any supported by the
> actual event device).
>
Seems reasonable if we want to re-define this. I'm fine either way and can
add such a change to a v2 patchset if there is consensus on it.
/Bruce
On Tue, Nov 21, 2023 at 10:30:02AM +0100, Mattias Rönnblom wrote:
> On 2023-11-20 18:25, Bruce Richardson wrote:
> > Not all eventdev's support all scheduling types, for example, some may
> > only support atomic scheduling or others only support ordered
> > scheduling. There is currently no clear indication for each driver what
> > sched types it supports, so add capability flags to be indicated on
> > return from rte_event_dev_info_get() API.
> >
> > Similarly add the possible scheduling types to the capabilities table in
> > the docs.
> >
>
> Should we allow an event device to advertise
> RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES, but not all of these?
>
> With current wording of RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES prevents that, but
> you should be able to allow for this without breaking backward compatibility
> by tweaking the text from
>
> "Event device is capable of enqueuing events of any type to any queue."
>
> "Event device is capable of enqueuing events of any type advertised as
> supported (e.g., by RTE_EVENT_DEV_CAP_ATOMIC)."
>
> An event device that doesn't support ordered, but does support "all" types
> seems reasonable to me, while an event device that does support ordered on a
> per-event basis, but doesn't for queue-level configuration does not.
>
> If RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES is left unchanged, the user may ask
> herself what "any" means (any supported in the API, or any supported by the
> actual event device).
>
Two follow-up thoughts on this:
1. The use of this ALL_TYPES flag would suggest to me that we should not have
SINGLE_LINK as an explicit queue type, in the set of
ATOMIC/ORDERED/PARALLEL, as it would really confuse the issue as to what
exactly all-types means. Therefore, I think we should keep single-link
as an auxiliary hint as now.
2. The CAP_QUEUE_ALL_TYPES seems a rather blunt instrument, and I was
thinking that we would be better to convert it over to have the
alternative flag that says that queues only support a single-type.
However, even then, neither really covers the full gamut of support,
because in some cases whether or not queues support all types will
depend upon configuration. For example, for DLB2 driver, the docs point
out that depending upon config, a queue can support either atomic or
parallel, or atomic or ordered - with parallel "degrading" to ordered in
that case. It's possible we could have other PMDs which allow the final
combination of having a queue either atomic, or ordered and parallel
combined.
Not sure we have an easy mechanism to express all this, so probably
keeping the status quo - possibly with your suggested tweak - is good
enough for now. We also need to keep things as simple as possible for
app developers too, and try to avoid too many possible combinations.
/Bruce
Ideally, supporting ORing of schedule types during queue creation would have been best. But advertising all such possible combinations will be a nightmare.
But this will allow flexibility to create an exact combination HW can support. Either support all or a subset of it.
-----Original Message-----
From: Bruce Richardson <bruce.richardson@intel.com>
Sent: Tuesday, November 21, 2023 6:13 AM
To: Mattias Rönnblom <hofors@lysator.liu.se>
Cc: dev@dpdk.org; Jerin Jacob <jerinj@marvell.com>
Subject: Re: [PATCH 24.03 1/8] eventdev: add capability flags for supported sched types
On Tue, Nov 21, 2023 at 10:30:02AM +0100, Mattias Rönnblom wrote:
> On 2023-11-20 18:25, Bruce Richardson wrote:
> > Not all eventdev's support all scheduling types, for example, some
> > may only support atomic scheduling or others only support ordered
> > scheduling. There is currently no clear indication for each driver
> > what sched types it supports, so add capability flags to be
> > indicated on return from rte_event_dev_info_get() API.
> >
> > Similarly add the possible scheduling types to the capabilities
> > table in the docs.
> >
>
> Should we allow an event device to advertise
> RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES, but not all of these?
>
> With current wording of RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES prevents
> that, but you should be able to allow for this without breaking
> backward compatibility by tweaking the text from
>
> "Event device is capable of enqueuing events of any type to any queue."
>
> "Event device is capable of enqueuing events of any type advertised as
> supported (e.g., by RTE_EVENT_DEV_CAP_ATOMIC)."
>
> An event device that doesn't support ordered, but does support "all"
> types seems reasonable to me, while an event device that does support
> ordered on a per-event basis, but doesn't for queue-level configuration does not.
>
> If RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES is left unchanged, the user may
> ask herself what "any" means (any supported in the API, or any
> supported by the actual event device).
>
Two follow-up thoughts on this:
1. The use of this ALL_TYPES flag would suggest to me that we should not have
SINGLE_LINK as an explicit queue type, in the set of
ATOMIC/ORDERED/PARALLEL, as it would really confuse the issue as to what
exactly all-types means. Therefore, I think we should keep single-link
as an auxiliary hint as now.
2. The CAP_QUEUE_ALL_TYPES seems a rather blunt instrument, and I was
thinking that we would be better to convert it over to have the
alternative flag that says that queues only support a single-type.
However, even then, neither really covers the full gamut of support,
because in some cases whether or not queues support all types will
depend upon configuration. For example, for DLB2 driver, the docs point
out that depending upon config, a queue can support either atomic or
parallel, or atomic or ordered - with parallel "degrading" to ordered in
that case. It's possible we could have other PMDs which allow the final
combination of having a queue either atomic, or ordered and parallel
combined.
Not sure we have an easy mechanism to express all this, so probably
keeping the status quo - possibly with your suggested tweak - is good
enough for now. We also need to keep things as simple as possible for
app developers too, and try to avoid too many possible combinations.
/Bruce
@@ -6,6 +6,9 @@
; the features table in the documentation.
;
[Scheduling Features]
+atomic_scheduling =
+ordered_scheduling =
+parallel_scheduling =
queue_qos =
event_qos =
distributed_sched =
@@ -326,6 +326,27 @@ struct rte_event;
* than one.
*/
+#define RTE_EVENT_DEV_CAP_ATOMIC (1ULL << 13)
+/**< Event device is capable of atomic scheduling.
+ * When this flag is set, the application can configure queues with scheduling type
+ * atomic on this event device.
+ * @see RTE_SCHED_TYPE_ATOMIC
+ */
+
+#define RTE_EVENT_DEV_CAP_ORDERED (1ULL << 13)
+/**< Event device is capable of ordered scheduling.
+ * When this flag is set, the application can configure queues with scheduling type
+ * ordered on this event device.
+ * @see RTE_SCHED_TYPE_ORDERED
+ */
+
+#define RTE_EVENT_DEV_CAP_PARALLEL (1ULL << 13)
+/**< Event device is capable of parallel scheduling.
+ * When this flag is set, the application can configure queues with scheduling type
+ * parallel on this event device.
+ * @see RTE_SCHED_TYPE_PARALLEL
+ */
+
/* Event device priority levels */
#define RTE_EVENT_DEV_PRIORITY_HIGHEST 0
/**< Highest priority expressed across eventdev subsystem