[PATCH 24.03 1/8] eventdev: add capability flags for supported sched types

[Bruce Richardson]

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