From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 236CA5585 for ; Fri, 18 Nov 2016 16:25:22 +0100 (CET) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga102.jf.intel.com with ESMTP; 18 Nov 2016 07:25:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,510,1473145200"; d="scan'208";a="32854164" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.64]) by orsmga005.jf.intel.com with SMTP; 18 Nov 2016 07:25:19 -0800 Received: by (sSMTP sendmail emulation); Fri, 18 Nov 2016 15:25:19 +0000 Date: Fri, 18 Nov 2016 15:25:18 +0000 From: Bruce Richardson To: Jerin Jacob Cc: dev@dpdk.org, harry.van.haaren@intel.com, hemant.agrawal@nxp.com, gage.eads@intel.com Message-ID: <20161118152518.GA121080@bricha3-MOBL3.ger.corp.intel.com> References: <1479447902-3700-1-git-send-email-jerin.jacob@caviumnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1479447902-3700-1-git-send-email-jerin.jacob@caviumnetworks.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 15:25:23 -0000 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