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

[Pathak, Pravin]

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 at intel.com> 
Sent: Tuesday, November 21, 2023 6:13 AM
To: Mattias Rönnblom <hofors at lysator.liu.se>
Cc: dev at dpdk.org; Jerin Jacob <jerinj at 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