From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 249AFFB8A for ; Tue, 20 Dec 2016 14:22:55 +0100 (CET) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga104.jf.intel.com with ESMTP; 20 Dec 2016 05:22:54 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,378,1477983600"; d="scan'208";a="41830085" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.64]) by orsmga004.jf.intel.com with SMTP; 20 Dec 2016 05:22:52 -0800 Received: by (sSMTP sendmail emulation); Tue, 20 Dec 2016 13:22:51 +0000 Date: Tue, 20 Dec 2016 13:22:51 +0000 From: Bruce Richardson To: Jerin Jacob Cc: dev@dpdk.org, thomas.monjalon@6wind.com, hemant.agrawal@nxp.com, gage.eads@intel.com, harry.van.haaren@intel.com Message-ID: <20161220132251.GA211688@bricha3-MOBL3.ger.corp.intel.com> References: <1480798539-13360-1-git-send-email-jerin.jacob@caviumnetworks.com> <1482070895-32491-1-git-send-email-jerin.jacob@caviumnetworks.com> <20161220111342.GA201880@bricha3-MOBL3.ger.corp.intel.com> <20161220130929.GA5901@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161220130929.GA5901@localhost.localdomain> Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.7.1 (2016-10-04) Subject: Re: [dpdk-dev] [PATCH v3 0/6] libeventdev API and northbound implementation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 13:22:56 -0000 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