From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 188532C8 for ; Tue, 22 Nov 2016 02:59:19 +0100 (CET) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga105.fm.intel.com with ESMTP; 21 Nov 2016 17:59:19 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,678,1473145200"; d="scan'208";a="34211966" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by fmsmga005.fm.intel.com with ESMTP; 21 Nov 2016 17:59:17 -0800 Date: Tue, 22 Nov 2016 10:00:14 +0800 From: Yuanhan Liu To: Jerin Jacob Cc: Bruce Richardson , dev@dpdk.org, harry.van.haaren@intel.com, hemant.agrawal@nxp.com, gage.eads@intel.com, thomas.monjalon@6wind.com Message-ID: <20161122020014.GU5048@yliu-dev.sh.intel.com> References: <1479447902-3700-1-git-send-email-jerin.jacob@caviumnetworks.com> <20161118152518.GA121080@bricha3-MOBL3.ger.corp.intel.com> <20161118160428.GA123692@bricha3-MOBL3.ger.corp.intel.com> <20161118192715.GA8674@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161118192715.GA8674@localhost.localdomain> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH 0/4] libeventdev API and northbound implementation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 01:59:20 -0000 On Sat, Nov 19, 2016 at 12:57:15AM +0530, Jerin Jacob wrote: > On Fri, Nov 18, 2016 at 04:04:29PM +0000, Bruce Richardson wrote: > > +Thomas > > > > On Fri, Nov 18, 2016 at 03:25:18PM +0000, Bruce Richardson wrote: > > > On Fri, Nov 18, 2016 at 11:14:58AM +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 > > > > > > > > Changes since RFC v2: > > > > > > > > - Updated the documentation to define the need for this library[Jerin] > > > > - Added RTE_EVENT_QUEUE_CFG_*_ONLY configuration parameters in > > > > struct rte_event_queue_conf to enable optimized sw implementation [Bruce] > > > > - Introduced RTE_EVENT_OP* ops [Bruce] > > > > - Added nb_event_queue_flows,nb_event_port_dequeue_depth, nb_event_port_enqueue_depth > > > > in rte_event_dev_configure() like ethdev and crypto library[Jerin] > > > > - Removed rte_event_release() and replaced with RTE_EVENT_OP_RELEASE ops to > > > > reduce fast path APIs and it is redundant too[Jerin] > > > > - In the view of better application portability, Removed pin_event > > > > from rte_event_enqueue as it is just hint and Intel/NXP can not support it[Jerin] > > > > - Added rte_event_port_links_get()[Jerin] > > > > - Added rte_event_dev_dump[Harry] > > > > > > > > Notes: > > > > > > > > - This patch set is check-patch clean with an exception that > > > > 02/04 has one WARNING:MACRO_WITH_FLOW_CONTROL > > > > - Looking forward to getting additional maintainers for libeventdev > > > > > > > > > > > > Possible next steps: > > > > 1) Review this patch set > > > > 2) Integrate Intel's SW driver[http://dpdk.org/dev/patchwork/patch/17049/] > > > > 3) Review proposed examples/eventdev_pipeline application[http://dpdk.org/dev/patchwork/patch/17053/] > > > > 4) Review proposed functional tests[http://dpdk.org/dev/patchwork/patch/17051/] > > > > 5) Cavium's HW based eventdev driver > > > > > > > > I am planning to work on (3),(4) and (5) > > > > > > > Thanks Jerin, > > > > > > we'll review and get back to you with any comments or feedback (1), and > > > obviously start working on item (2) also! :-) > > > > > > I'm also wonder whether we should have a staging tree for this work to > > > make interaction between us easier. Although this may not be > > > finalised enough for 17.02 release, do you think having an > > > dpdk-eventdev-next tree would be a help? My thinking is that once we get > > > the eventdev library itself in reasonable shape following our review, we > > > could commit that and make any changes thereafter as new patches, rather > > > than constantly respinning the same set. It also gives us a clean git > > > tree to base the respective driver implementations on from our two sides. > > > > > > Thomas, any thoughts here on your end - or from anyone else? > > I was thinking more or less along the same lines. To avoid re-spinning the > same set, it is better to have libeventdev library mark as EXPERIMENTAL > and commit it somewhere on dpdk-eventdev-next or main tree > > I think, EXPERIMENTAL status can be changed only when > - At least two event drivers available > - Functional test applications fine with at least two drivers > - Portable example application to showcase the features of the library > - eventdev integration with another dpdk subsystem such as ethdev I'm wondering maybe we could have a staging tree, for all features like this one (and one branch for each feature)? --yliu