On Tue, Nov 21, 2023 at 09:44:37AM +0000, Bruce Richardson wrote: > On Tue, Nov 21, 2023 at 10:32:07AM +0100, Mattias Rönnblom wrote: > > On 2023-11-21 10:30, Mattias Rönnblom wrote: > > > On 2023-11-20 18:26, Bruce Richardson wrote: > > > > Document explicitly the scheduling types supported by this driver, both > > > > via info_get() function, and via table in the documentation. > > > > > > > > Signed-off-by: Bruce Richardson <bruce.richard...@intel.com> > > > > --- > > > > doc/guides/eventdevs/features/dsw.ini | 1 + > > > > drivers/event/dsw/dsw_evdev.c | 1 + > > > > 2 files changed, 2 insertions(+) > > > > > > > > diff --git a/doc/guides/eventdevs/features/dsw.ini > > > > b/doc/guides/eventdevs/features/dsw.ini > > > > index c8bc6b3f1d..941d257e3d 100644 > > > > --- a/doc/guides/eventdevs/features/dsw.ini > > > > +++ b/doc/guides/eventdevs/features/dsw.ini > > > > @@ -4,6 +4,7 @@ > > > > ; Refer to default.ini for the full list of available PMD features. > > > > ; > > > > [Scheduling Features] > > > > +atomic_scheduling = Y > > > > distributed_sched = Y > > > > burst_mode = Y > > > > nonseq_mode = Y > > > > diff --git a/drivers/event/dsw/dsw_evdev.c > > > > b/drivers/event/dsw/dsw_evdev.c > > > > index 1209e73a9d..a68ca1fe30 100644 > > > > --- a/drivers/event/dsw/dsw_evdev.c > > > > +++ b/drivers/event/dsw/dsw_evdev.c > > > > @@ -220,6 +220,7 @@ dsw_info_get(struct rte_eventdev *dev __rte_unused, > > > > .max_num_events = DSW_MAX_EVENTS, > > > > .max_profiles_per_port = 1, > > > > .event_dev_cap = RTE_EVENT_DEV_CAP_BURST_MODE| > > > > + RTE_EVENT_DEV_CAP_ATOMIC | > > > > RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED| > > > > RTE_EVENT_DEV_CAP_NONSEQ_MODE| > > > > RTE_EVENT_DEV_CAP_MULTIPLE_QUEUE_PORT| > > > > -- > > > > 2.39.2 > > > > > > > > > > Acked-by: Mattias Rönnblom <mattias.ronnb...@ericsson.com> > > > > Eh, hold on. PARALLEL is also supported. > > > > Sorry, missed that. Will add in V2. > > > Do we need a capability for single link as well? > > I was wondering about that myself. For this v1 I decided against it > because any ordered or atomic queue can be single link by just binding it > to a single port. The actual single link flag is jut a hint allow the > driver to be more efficient about resourcing. > However, if you think it's worthwhile calling out explicitly I can > certainly add it.
If we have such a flag, we should look to have eventdev "emulate" single-link via ordered or atomic queues for drivers that don't directly support it. I'm concerned that the number of different capability options makes it difficult to write truly portable apps. /Bruce
