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
