From: Jerin Jacob <jerinjacobk@gmail.com>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: dev@dpdk.org, "Mattias Rönnblom" <hofors@lysator.liu.se>,
"Jerin Jacob" <jerinj@marvell.com>
Subject: Re: [PATCH 24.03 v2 2/9] eventdev: increase flexibility of all-types flag
Date: Tue, 12 Dec 2023 18:17:47 +0530 [thread overview]
Message-ID: <CALBAE1MsgbfaSupOa8UMrFpBD93p9JZE7zOiDsH0CGz3gSu1tg@mail.gmail.com> (raw)
In-Reply-To: <ZXhD3OuvUNl7TPt8@bricha3-MOBL.ger.corp.intel.com>
On Tue, Dec 12, 2023 at 4:58 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> On Thu, Nov 23, 2023 at 09:37:58AM +0530, Jerin Jacob wrote:
> > On Tue, Nov 21, 2023 at 5:25 PM Bruce Richardson
> > <bruce.richardson@intel.com> wrote:
> > >
> > > Rather than requiring that any device advertising the
> > > RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES flag support all of atomic, ordered
> > > and parallel scheduling, we can redefine the field so that it basically
> > > means that you don't need to specify the queue scheduling type at config
> > > time. Instead all types of supported events can be sent to all queues.
> > >
> > > Suggested-by: Mattias Rönnblom <hofors@lysator.liu.se>
> > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > ---
> > > lib/eventdev/rte_eventdev.h | 15 ++++++++++++---
> > > 1 file changed, 12 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
> > > index d48957362c..1c5043de26 100644
> > > --- a/lib/eventdev/rte_eventdev.h
> > > +++ b/lib/eventdev/rte_eventdev.h
> > > @@ -250,11 +250,20 @@ struct rte_event;
> > > * @see rte_event_dequeue_burst()
> > > */
> > > #define RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES (1ULL << 3)
> > > -/**< Event device is capable of enqueuing events of any type to any queue.
> > > +/**< Event device is capable of accepting enqueued events, of any type
> > > + * advertised as supported by the device, to all destination queues.
> > > + *
> > > + * When this capability is set, the "schedule_type" field of the
> > > + * rte_event_queue_conf structure is ignored when a queue is being configured.
> >
> > can we also add something like below or so to above line
> >
> > rte_event_queue_conf structure is ignored when a queue is being
> > configured instead rte_event::sched_type
> > shall be used.
> >
> Preparing v3 now and including this doc change. However, I'm also wondering
> about the correct behaviour when this flag is not set. When the flag is not
> set, the events enqueued should match the event type of the queue, but do
> we need to enforce this, or should we?
>
> Couple of options:
> 1. Actually enforce this, and state that it is an error to enqueue events
> with another scheduling type.
> 2. Explicitly not enforce this, and just state instead that the sched_type
> of events will be ignored.
>
> Personally, I'd tend very much towards #2. because:
> * it's easier for the app, as they can ignore the sched_type field through
> the pipeline if they want, relying on each queues type to do the right
> thing. This could be especially useful if they have fallback mechanisms
> to e.g. configure a queue as atomic if reordered is not supported etc.
> The downside is that for portable applications the sched type
> should always be set anyway, but the app doesn't lose anything in this
> case with #2 over #1.
>
> * It's easier and more performant for the drivers, since it's one less
> check that should be performed on enqueue. The driver can just blindly
> override the sched_type provided with the queue config version.
>
> I actually think an extension of #2 would also be nice to have for
> portability, whereby an app could explicitly configure a queue to only have
> a scheduling type - event if it's all-types-capable - and thereafter never
> have to set the sched_type field on events. The drivers would always
> remember the queue-type and explicitly set that if necessary on enqueue
>
> Thoughts?
HW queues with All-type support will be costly resources, so making a
portable program
we need to spare 3 queues instead of 1 queue.
Considering the difference in eventdev capabilities, I see the most
reliable option is
end user focus on reusable packet processing stages. Have worker skeleton based
on HW device capabilities, as there are enough HW differences across
event devices.
That is the kind of theme followed in testeventdev.
> /Bruce
>
> PS: Going to send v3 now anyway, based on feedback thus far. If we get
> quick consensus on above, I can roll it into a v4, otherwise we can look to
Let's go with v3 now. Later we can discuss more on this latter.
> clarify that situation in a separate patch later.
next prev parent reply other threads:[~2023-12-12 12:48 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
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 [this message]
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=CALBAE1MsgbfaSupOa8UMrFpBD93p9JZE7zOiDsH0CGz3gSu1tg@mail.gmail.com \
--to=jerinjacobk@gmail.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).