Re: [RFC PATCH] eventdev: add buffered enqueue and flush APIs

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: [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.