From: "Eads, Gage" <gage.eads@intel.com>
To: "Mattias Rönnblom" <mattias.ronnblom@ericsson.com>,
"Jerin Jacob" <jerinjacobk@gmail.com>
Cc: dpdk-dev <dev@dpdk.org>, Jerin Jacob <jerinj@marvell.com>,
"Richardson, Bruce" <bruce.richardson@intel.com>
Subject: Re: [dpdk-dev] [RFC 1/3] eventdev: allow for event devices requiring maintenance
Date: Thu, 9 Apr 2020 13:33:35 +0000 [thread overview]
Message-ID: <DM5PR11MB12594FA5ADC29A9432FC8F7EF6C10@DM5PR11MB1259.namprd11.prod.outlook.com> (raw)
In-Reply-To: <86ff8b8f-7865-7fe2-f853-e88d2a64347d@ericsson.com>
> >> diff --git a/lib/librte_eventdev/rte_eventdev.h
> >> b/lib/librte_eventdev/rte_eventdev.h
> >> index 226f352ad..d69150792 100644
> >> --- a/lib/librte_eventdev/rte_eventdev.h
> >> +++ b/lib/librte_eventdev/rte_eventdev.h
> >> @@ -289,6 +289,15 @@ struct rte_event;
> >> * single queue to each port or map a single queue to many port.
> >> */
> >>
> >> +#define RTE_EVENT_DEV_CAP_REQUIRES_MAINT (1ULL << 9) /**<
> Event
> >> +device requires calls to rte_event_maintain() during
> > This scheme would call for DSW specific API handling in fastpath.
>
>
> Initially this would be so, but buffering events might yield performance
> benefits for more event devices than DSW.
>
I agree. For applications that process and enqueue one event at a time, buffering in the PMD could give a performance boost with minimal code changes (assuming the application can tolerate higher packet latency caused by buffering).
>
> In an application, it's often convenient, but sub-optimal from a
> performance point of view, to do single-event enqueue operations. The
> alternative is to use an application-level buffer, and the flush this
> buffer with rte_event_enqueue_burst(). If you allow the event device to
> buffer, you get the simplicity of single-event enqueue operations, but
> without taking any noticeable performance hit.
>
>
> >> + * periods when neither rte_event_dequeue_burst() nor
> > The typical worker thread will be
> > while (1) {
> > rte_event_dequeue_burst();
> > ..proess..
> > rte_event_enqueue_burst();
> > }
> > If so, Why DSW driver can't do the maintenance in driver context in
> > dequeue() call.
> >
>
> DSW already does maintenance on dequeue, and works well in the above
> scenario. The typical worker does not need to care about the
> rte_event_maintain() functions, since it dequeues events on a regular basis.
>
>
> What this RFC addresses is the more atypical (but still fairly common)
> case of a port being neither dequeued to or enqueued from on a regular
> basis. The timer and ethernet rx adapters are examples of such.
>
Those two adapters have application-level buffering already, so adding PMD-level buffering feels unnecessary. Could DSW support this behavior on a port-by-port basis?
If so, I'm picturing something like:
- Add a "PMD buffering" eventdev capability
- If an eventdev has that capability, its ports can be configured for PMD-level buffering (default: no buffering)
-- Convert " uint8_t disable_implicit_release" to a flags bitmap (e.g. "uint8_t event_port_cfg"), with one flag for implicit release disable and another for PMD-level buffering
-- I suspect we can maintain ABI compatibility with function versioning on rte_event_port_setup() and rte_event_port_default_conf_get(), and this flags bitmap could be extended out to 32 bits in 20.11.
- Add "flush" semantics either to a new interface or extend an existing one. I'm partial to a new interface, to avoid an additional check in e.g. the dequeue code. And putting the flush in dequeue doesn't allow an app to batch across multiple iterations of the dequeue-process-enqueue loop.
- Extend rte_event_port_attr_get() to allow users to query this new setting. Adapters that don't call the flush function could error out if the adapter's port is configured for PMD-level buffering.
(eventdev should also forbid "PMD-level buffering" and "implicit release" used together...it's easy to imagine double-release errors occurring otherwise.)
I think this accomplishes Mattias' objective, and there's no effect on existing apps or adapters unless they choose to enable this behavior.
Granted, existing apps would likely see performance loss with dsw until they enable this config option. But perhaps it's worth it to get this behavior properly supported in the interface.
Thanks,
Gage
next prev parent reply other threads:[~2020-04-09 13:33 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-08 17:56 Mattias Rönnblom
2020-04-08 17:56 ` [dpdk-dev] [RFC 2/3] event/dsw: make use of eventdev maintenance facility Mattias Rönnblom
2020-04-08 17:56 ` [dpdk-dev] [RFC 3/3] eventdev: allow devices requiring maintenance with adapters Mattias Rönnblom
2020-04-08 19:36 ` [dpdk-dev] [RFC 1/3] eventdev: allow for event devices requiring maintenance Jerin Jacob
2020-04-09 12:21 ` Mattias Rönnblom
2020-04-09 13:32 ` Jerin Jacob
2020-04-09 14:02 ` Mattias Rönnblom
2020-04-10 13:00 ` Jerin Jacob
2020-04-14 15:57 ` Mattias Rönnblom
2020-04-14 16:15 ` Jerin Jacob
2020-04-14 17:55 ` Mattias Rönnblom
2020-04-16 17:19 ` Jerin Jacob
2020-04-20 9:05 ` Mattias Rönnblom
2020-05-13 18:56 ` Mattias Rönnblom
2021-08-02 16:14 ` [dpdk-dev] [RFC v2 " Mattias Rönnblom
2021-08-02 16:15 ` [dpdk-dev] [RFC v2 2/3] event/dsw: make use of eventdev maintenance facility Mattias Rönnblom
2021-08-02 16:15 ` [dpdk-dev] [RFC v2 3/3] eventdev: have adapters support device maintenance Mattias Rönnblom
2021-08-03 4:39 ` [dpdk-dev] [RFC v2 1/3] eventdev: allow for event devices requiring maintenance Jerin Jacob
2021-08-03 8:26 ` Mattias Rönnblom
2021-08-03 10:06 ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2021-10-26 17:31 ` [dpdk-dev] [PATCH " Mattias Rönnblom
2021-10-26 17:31 ` [dpdk-dev] [PATCH 2/3] event/dsw: make use of eventdev maintenance facility Mattias Rönnblom
2021-10-26 17:31 ` [dpdk-dev] [PATCH 3/3] eventdev: have adapters support device maintenance Mattias Rönnblom
2021-10-29 14:38 ` [dpdk-dev] [PATCH 1/3] eventdev: allow for event devices requiring maintenance Jerin Jacob
2021-10-29 15:03 ` Mattias Rönnblom
2021-10-29 15:17 ` Jerin Jacob
2021-10-29 16:02 ` Van Haaren, Harry
2021-10-31 9:29 ` Mattias Rönnblom
2021-10-30 17:19 ` Mattias Rönnblom
2021-10-31 13:17 ` Jerin Jacob
2021-11-01 13:28 ` [dpdk-dev] [PATCH v2 " Mattias Rönnblom
2021-11-01 13:28 ` [dpdk-dev] [PATCH v2 2/3] event/dsw: make use of eventdev maintenance facility Mattias Rönnblom
2021-11-01 13:28 ` [dpdk-dev] [PATCH v2 3/3] eventdev: have adapters support device maintenance Mattias Rönnblom
2021-11-04 12:33 ` [dpdk-dev] [PATCH 1/3] eventdev: allow for event devices requiring maintenance Jerin Jacob
2021-11-01 9:26 ` Mattias Rönnblom
2021-11-01 18:40 ` [dpdk-dev] [PATCH v3 " Mattias Rönnblom
2021-11-01 18:40 ` [dpdk-dev] [PATCH v3 2/3] event/dsw: make use of eventdev maintenance facility Mattias Rönnblom
2021-11-01 18:40 ` [dpdk-dev] [PATCH v3 3/3] eventdev: have adapters support device maintenance Mattias Rönnblom
2020-04-09 13:33 ` Eads, Gage [this message]
2020-04-09 14:14 ` [dpdk-dev] [RFC 1/3] eventdev: allow for event devices requiring maintenance Mattias Rönnblom
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=DM5PR11MB12594FA5ADC29A9432FC8F7EF6C10@DM5PR11MB1259.namprd11.prod.outlook.com \
--to=gage.eads@intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=jerinj@marvell.com \
--cc=jerinjacobk@gmail.com \
--cc=mattias.ronnblom@ericsson.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).