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