From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 5F1402C40 for ; Fri, 18 Nov 2016 17:04:33 +0100 (CET) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga105.jf.intel.com with ESMTP; 18 Nov 2016 08:04:32 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,510,1473145200"; d="scan'208";a="32865822" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.64]) by orsmga005.jf.intel.com with SMTP; 18 Nov 2016 08:04:30 -0800 Received: by (sSMTP sendmail emulation); Fri, 18 Nov 2016 16:04:29 +0000 Date: Fri, 18 Nov 2016 16:04:29 +0000 From: Bruce Richardson To: Jerin Jacob Cc: dev@dpdk.org, harry.van.haaren@intel.com, hemant.agrawal@nxp.com, gage.eads@intel.com, thomas.monjalon@6wind.com Message-ID: <20161118160428.GA123692@bricha3-MOBL3.ger.corp.intel.com> References: <1479447902-3700-1-git-send-email-jerin.jacob@caviumnetworks.com> <20161118152518.GA121080@bricha3-MOBL3.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161118152518.GA121080@bricha3-MOBL3.ger.corp.intel.com> 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 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: Fri, 18 Nov 2016 16:04:34 -0000 +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? > > Regards, > /Bruce >