DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Eads, Gage" <gage.eads@intel.com>
To: Jerin Jacob <jerin.jacob@caviumnetworks.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: "Richardson, Bruce" <bruce.richardson@intel.com>,
	"Van Haaren, Harry" <harry.van.haaren@intel.com>,
	Hemant Agrawal <hemant.agrawal@nxp.com>,
	Nipun Gupta <nipun.gupta@nxp.com>,
	"Rao, Nikhil" <nikhil.rao@intel.com>,
	Pavan Nikhilesh <pbhagavatula@caviumnetworks.com>,
	Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [dpdk-dev] [PATCH] eventdev: remove experimental label
Date: Mon, 23 Oct 2017 18:27:52 +0000	[thread overview]
Message-ID: <9184057F7FC11744A2107296B6B8EB1E1400BE33@FMSMSX108.amr.corp.intel.com> (raw)
In-Reply-To: <20171016103255.16322-1-jerin.jacob@caviumnetworks.com>

Hi Jerin,

I have one concern with the API that may delay changing the label.

The implicit release that in rte_event_dequeue_burst() is a problem when using asynchronous/look-aside hardware, like a cryptodev. For instance, let's say in pipeline stage N the worker takes the event's mbuf and places it in a per-worker crypto request queue. When the worker next calls rte_event_dequeue_burst(), that function will release the previous event which could cause the flow to migrate to another worker, and this could result in packet reordering.

To prevent this, the worker can't call dequeue until the look-aside operation completes...in effect treating the asynchronous/look-aside hardware as synchronous. Another option is to feed stage N's queue to a single port to avoid the flow migration, but that port may become a bottleneck.

We could remove the implicit release functionality or add a port configuration flag to disable it, so the default behavior is unchanged. Removing it will completely will likely require changes in existing code, but it simplifies the usage model (all dequeued events must be either forwarded or released) and the PMD's dequeue code. This functionality could be removed from the software eventdev fairly easily, but I haven't looked into the hardware PMDs.

Thanks,
Gage

> -----Original Message-----
> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> Sent: Monday, October 16, 2017 5:33 AM
> To: dev@dpdk.org
> Cc: Jerin Jacob <jerin.jacob@caviumnetworks.com>; Richardson, Bruce
> <bruce.richardson@intel.com>; Van Haaren, Harry
> <harry.van.haaren@intel.com>; Eads, Gage <gage.eads@intel.com>; Hemant
> Agrawal <hemant.agrawal@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>;
> Rao, Nikhil <nikhil.rao@intel.com>; Pavan Nikhilesh
> <pbhagavatula@caviumnetworks.com>; Thomas Monjalon
> <thomas@monjalon.net>
> Subject: [dpdk-dev] [PATCH] eventdev: remove experimental label
> 
> The eventdev API was introduced in DPDK 17.05 release.
> Since then it
> - has been reviewed and iterated for 17.08, 17.11 releases
> - three drivers were implemented using the API.
> - introduced another subsystem like service core and ethdev-eventdev Rx
> adapter APIs to abstract the difference between HW and SW eventdev
> implementations in a transparent way.
> - had extensive use by the app/test-eventdev/ and
> examples/eventdev_pipeline_sw_pmd/
> 
> I believe the API is now stable and the EXPERIMENTAL label should be removed.
> 
> CC: Bruce Richardson <bruce.richardson@intel.com>
> CC: Harry van Haaren <harry.van.haaren@intel.com>
> CC: Gage Eads <gage.eads@intel.com>
> CC: Hemant Agrawal <hemant.agrawal@nxp.com>
> CC: Nipun Gupta <nipun.gupta@nxp.com>
> CC: Nikhil Rao <nikhil.rao@intel.com>
> CC: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com>
> CC: Thomas Monjalon <thomas@monjalon.net>
> Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> ---
> 
> There are two more outstanding eventdev API changes. Please find below.
> Please express if you have any concern in changing those APIs. I would
> like to fix this API issue and remove experimental tag in v17.11,
> if we all agree.
> 
> - evendev: fix inconsistency in event queue config
> http://dpdk.org/dev/patchwork/patch/30293/
> - remove rte_event_schedule() API and use service core infrastructure
> http://dpdk.org/dev/patchwork/patch/30375/
> 
> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2a58378b7..4a4be3a54 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -262,7 +262,7 @@ F: lib/librte_cryptodev/
>  F: test/test/test_cryptodev*
>  F: examples/l2fwd-crypto/
> 
> -Eventdev API - EXPERIMENTAL
> +Eventdev API
>  M: Jerin Jacob <jerin.jacob@caviumnetworks.com>
>  T: git://dpdk.org/next/dpdk-next-eventdev
>  F: lib/librte_eventdev/
> --
> 2.14.2

  reply	other threads:[~2017-10-23 18:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-16 10:32 Jerin Jacob
2017-10-23 18:27 ` Eads, Gage [this message]
2017-10-30 17:38   ` Jerin Jacob
2017-11-01 14:12     ` Eads, Gage
2017-11-02  4:11       ` Jerin Jacob
2017-11-02 14:19         ` Eads, Gage
2017-11-07 22:16           ` Thomas Monjalon

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=9184057F7FC11744A2107296B6B8EB1E1400BE33@FMSMSX108.amr.corp.intel.com \
    --to=gage.eads@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=harry.van.haaren@intel.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=nikhil.rao@intel.com \
    --cc=nipun.gupta@nxp.com \
    --cc=pbhagavatula@caviumnetworks.com \
    --cc=thomas@monjalon.net \
    /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).