On Mon, Dec 12, 2016 at 05:56:32PM +0000, Eads, Gage wrote: > > > > -----Original Message----- > > From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com] > > Sent: Wednesday, December 7, 2016 10:42 PM > > To: Eads, Gage <gage.e...@intel.com> > > Cc: dev@dpdk.org; Richardson, Bruce <bruce.richard...@intel.com>; Van > > Haaren, Harry <harry.van.haa...@intel.com>; hemant.agra...@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.ja...@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.
