[dpdk-dev] [PATCH v3 0/6] libeventdev API and northbound implementation

[Bruce Richardson]

On Tue, Dec 20, 2016 at 06:39:30PM +0530, Jerin Jacob wrote:
> On Tue, Dec 20, 2016 at 11:13:42AM +0000, Bruce Richardson wrote:
> > On Sun, Dec 18, 2016 at 07:51:29PM +0530, Jerin Jacob wrote:
> > > As previously discussed in RFC v1 [1], RFC v2 [2], with changes
> > > described in [3] (also pasted below), here is the first non-draft series
> > > for this new API.
> > > 
> > > [1] http://dpdk.org/ml/archives/dev/2016-August/045181.html
> > > [2] http://dpdk.org/ml/archives/dev/2016-October/048592.html
> > > [3] http://dpdk.org/ml/archives/dev/2016-October/048196.html
> > > 
> > > v2..v3:
> > > 
> > > - This patch set is check-patch clean with an exception that
> > > 03/06 has one WARNING:MACRO_WITH_FLOW_CONTROL
> > > - Looking forward to getting additional maintainers for libeventdev
> > > 
> > > TODO:
> > > 1) Create user guide
> > > 
> > > Jerin Jacob (6):
> > >   eventdev: introduce event driven programming model
> > >   eventdev: define southbound driver interface
> > >   eventdev: implement the northbound APIs
> > >   eventdev: implement PMD registration functions
> > >   event/skeleton: add skeleton eventdev driver
> > >   app/test: unit test case for eventdev APIs
> > > 
> > Hi Jerin,
> 
> Hi Bruce,
> 
> > 
> > other than the couple of comments I've made in replies to the individual
> > patches, this looks pretty good to me. Only additional comment I have is
> 
> Thanks
> 
> > that some of the macro names are a little long, and maybe we can shorten
> > them  For example, you've added "_FLAG_" into the config flag macros,
> > and I'm not sure that is necessary. Similarly, I think we can drop
> > "_DEV_" from the PRIORITY names to shorten them.
> 
> OK. I will remove the explicit _FLAG_  to shorten macro name.
> The _DEV_ in PRIORITY is not that long. So I would like to keep it for
> consistency and to denote it across priorities in event dev.
> 
> > 
> > Irrespective of these naming suggestions, once the other couple of
> > comments are taken care of, I think this set is suitable for merging to
> > the next-event tree.
> 
> I will send v4 with fixes and your suggestions. If their is no further
> comment on that, we will merge to next-event tree
> 
I'm not sure a v4 is needed, unless you especially want to do one. 
Given the scope of the suggested changes I think you can just make
those changes on apply to the next-event tree.

/Bruce