From: "Pathak, Pravin" <pravin.pathak@intel.com>
To: "Richardson, Bruce" <bruce.richardson@intel.com>,
"Mattias Rönnblom" <hofors@lysator.liu.se>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Jerin Jacob <jerinj@marvell.com>
Subject: RE: [PATCH 24.03 1/8] eventdev: add capability flags for supported sched types
Date: Tue, 21 Nov 2023 17:08:12 +0000 [thread overview]
Message-ID: <BL1PR11MB5461850E9A74364884342B6BF4BBA@BL1PR11MB5461.namprd11.prod.outlook.com> (raw)
In-Reply-To: <ZVyQuxrkQ7OfZ6C/@bricha3-MOBL.ger.corp.intel.com>
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@intel.com>
Sent: Tuesday, November 21, 2023 6:13 AM
To: Mattias Rönnblom <hofors@lysator.liu.se>
Cc: dev@dpdk.org; Jerin Jacob <jerinj@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
next prev parent reply other threads:[~2023-11-21 17:08 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-20 17:25 [PATCH 24.03 0/8] document scheduling types for eventdev drivers Bruce Richardson
2023-11-20 17:25 ` [PATCH 24.03 1/8] eventdev: add capability flags for supported sched types Bruce Richardson
2023-11-20 17:48 ` Jerin Jacob
2023-11-20 17:52 ` Bruce Richardson
2023-11-21 9:30 ` Mattias Rönnblom
2023-11-21 9:46 ` Bruce Richardson
2023-11-21 11:12 ` Bruce Richardson
2023-11-21 17:08 ` Pathak, Pravin [this message]
2023-11-20 17:26 ` [PATCH 24.03 2/8] event/cnxk: add schedule-type capability flags Bruce Richardson
2023-11-20 17:26 ` [PATCH 24.03 3/8] event/dlb2: " Bruce Richardson
2023-11-20 22:45 ` Sevincer, Abdullah
2023-11-20 17:26 ` [PATCH 24.03 4/8] event/dpaa*: " Bruce Richardson
2023-11-21 10:51 ` Hemant Agrawal
2023-11-20 17:26 ` [PATCH 24.03 5/8] event/dsw: " Bruce Richardson
2023-11-21 9:30 ` Mattias Rönnblom
2023-11-21 9:32 ` Mattias Rönnblom
2023-11-21 9:44 ` Bruce Richardson
2023-11-21 9:47 ` Bruce Richardson
2023-11-20 17:26 ` [PATCH 24.03 6/8] event/octeontx: " Bruce Richardson
2023-11-20 17:26 ` [PATCH 24.03 7/8] event/opdl: " Bruce Richardson
2023-11-20 17:26 ` [PATCH 24.03 8/8] event/sw: " Bruce Richardson
2023-11-21 11:54 ` [PATCH 24.03 v2 0/9] document scheduling types for eventdev drivers Bruce Richardson
2023-11-21 11:54 ` [PATCH 24.03 v2 1/9] eventdev: add capability flags for supported sched types Bruce Richardson
2023-11-23 3:59 ` Jerin Jacob
2023-11-21 11:54 ` [PATCH 24.03 v2 2/9] eventdev: increase flexibility of all-types flag Bruce Richardson
2023-11-23 4:07 ` Jerin Jacob
2023-12-12 11:28 ` Bruce Richardson
2023-12-12 12:47 ` Jerin Jacob
2023-11-21 11:54 ` [PATCH 24.03 v2 3/9] event/cnxk: add schedule-type capability flags Bruce Richardson
2023-11-21 11:54 ` [PATCH 24.03 v2 4/9] event/dlb2: " Bruce Richardson
2023-11-21 11:54 ` [PATCH 24.03 v2 5/9] event/dpaa*: " Bruce Richardson
2023-11-21 11:54 ` [PATCH 24.03 v2 6/9] event/dsw: " Bruce Richardson
2023-11-21 11:54 ` [PATCH 24.03 v2 7/9] event/octeontx: " Bruce Richardson
2023-11-21 11:54 ` [PATCH 24.03 v2 8/9] event/opdl: " Bruce Richardson
2023-11-23 4:10 ` Jerin Jacob
2023-11-23 9:19 ` Bruce Richardson
2023-11-23 9:38 ` Jerin Jacob
2023-11-21 11:54 ` [PATCH 24.03 v2 9/9] event/sw: " Bruce Richardson
2023-12-12 11:32 ` [PATCH v3 0/9] document scheduling types for eventdev drivers Bruce Richardson
2023-12-12 11:32 ` [PATCH v3 1/9] eventdev: add capability flags for supported sched types Bruce Richardson
2023-12-12 11:32 ` [PATCH v3 2/9] eventdev: clarify all-types flag documentation Bruce Richardson
2023-12-13 12:50 ` Jerin Jacob
2023-12-13 13:20 ` Mattias Rönnblom
2023-12-12 11:32 ` [PATCH v3 3/9] event/cnxk: add schedule-type capability flags Bruce Richardson
2023-12-12 11:32 ` [PATCH v3 4/9] event/dlb2: " Bruce Richardson
2023-12-12 11:32 ` [PATCH v3 5/9] event/dpaa*: " Bruce Richardson
2023-12-12 11:32 ` [PATCH v3 6/9] event/dsw: " Bruce Richardson
2023-12-12 11:32 ` [PATCH v3 7/9] event/octeontx: " Bruce Richardson
2023-12-12 11:32 ` [PATCH v3 8/9] event/opdl: " Bruce Richardson
2023-12-12 11:32 ` [PATCH v3 9/9] event/sw: " Bruce Richardson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BL1PR11MB5461850E9A74364884342B6BF4BBA@BL1PR11MB5461.namprd11.prod.outlook.com \
--to=pravin.pathak@intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=hofors@lysator.liu.se \
--cc=jerinj@marvell.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).