DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: "Eads, Gage" <gage.eads@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"Van Haaren, Harry" <harry.van.haaren@intel.com>,
	"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>
Subject: Re: [dpdk-dev] [RFC PATCH] eventdev: add buffered enqueue and flush APIs
Date: Wed, 14 Dec 2016 13:22:20 +0530	[thread overview]
Message-ID: <20161214075219.GA24792@localhost.localdomain> (raw)
In-Reply-To: <9184057F7FC11744A2107296B6B8EB1E01E38655@FMSMSX108.amr.corp.intel.com>

On Mon, Dec 12, 2016 at 05:56:32PM +0000, Eads, Gage wrote:
> 
> 
> >  -----Original Message-----
> >  From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> >  Sent: Wednesday, December 7, 2016 10:42 PM
> >  To: Eads, Gage <gage.eads@intel.com>
> >  Cc: dev@dpdk.org; Richardson, Bruce <bruce.richardson@intel.com>; Van
> >  Haaren, Harry <harry.van.haaren@intel.com>; hemant.agrawal@nxp.com
> >  Subject: Re: [RFC PATCH] eventdev: add buffered enqueue and flush APIs
> >  
> >  On Mon, Dec 05, 2016 at 11:30:46PM +0000, Eads, Gage wrote:
> >  >
> >  > > On Dec 3, 2016, at 5:18 AM, Jerin Jacob
> >  <jerin.jacob@caviumnetworks.com> wrote:
> >  > >
> >  > >> On Fri, Dec 02, 2016 at 01:45:56PM -0600, Gage Eads wrote:
> >  > >> This commit adds buffered enqueue functionality to the eventdev API.
> >  > >> It is conceptually similar to the ethdev API's tx buffering,
> >  > >> however with a smaller API surface and no dropping of events.
> >  > >
> >  > > Hello Gage,
> >  > > Different implementation may have different strategies to hold the buffers.
> >  >
> >  > A benefit of inlining the buffering logic in the header is that we avoid the
> >  overhead of entering the PMD for what is a fairly simple operation (common
> >  case: add event to an array, increment counter). If we make this
> >  implementation-defined (i.e. use PMD callbacks), we lose that benefit.
> >  In general, I agree from the system perspective. But, few general issues with
> >  eventdev integration part,
> >  
> >  1) What if the burst has ATOMIC flows and if we are NOT en-queuing to the
> >  implementation then other event ports won't get the packets from the same
> >  ATOMIC tag ? BAD. Right?
> 
> I'm not sure what scenario you're describing here. The buffered (as implemented in my patch) and non-buffered enqueue operations are functionally the same (as long as the buffer is flushed), the difference lies in when the events are moved from the application level to the PMD.

Another point, we treat dequeue as _implicit_ event release of the
existing dequeued events, so with proposed buffering scheme breaks all the logic.

      parent reply	other threads:[~2016-12-14  7:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-02 19:45 [dpdk-dev] [RFC PATCH] EventDev buffered enqueue API Gage Eads
2016-12-02 19:45 ` [dpdk-dev] [RFC PATCH] eventdev: add buffered enqueue and flush APIs Gage Eads
2016-12-02 21:18   ` Jerin Jacob
2016-12-05 23:30     ` Eads, Gage
2016-12-08  4:41       ` Jerin Jacob
2016-12-12 17:56         ` Eads, Gage
2016-12-14  7:44           ` Jerin Jacob
2016-12-14  7:52           ` Jerin Jacob [this message]

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=20161214075219.GA24792@localhost.localdomain \
    --to=jerin.jacob@caviumnetworks.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=gage.eads@intel.com \
    --cc=harry.van.haaren@intel.com \
    --cc=hemant.agrawal@nxp.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).