From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shreyansh Jain Subject: Re: [PATCH 0/4] libeventdev API and northbound implementation Date: Tue, 22 Nov 2016 14:35:20 +0530 Message-ID: <4f5ca36a-fd9f-7589-bf6d-2a9d9639f2e8@nxp.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> <20161122020014.GU5048@yliu-dev.sh.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Cc: Bruce Richardson , , , , , To: Yuanhan Liu , Jerin Jacob Return-path: Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0066.outbound.protection.outlook.com [104.47.38.66]) by dpdk.org (Postfix) with ESMTP id BA21247D2 for ; Tue, 22 Nov 2016 10:03:16 +0100 (CET) In-Reply-To: <20161122020014.GU5048@yliu-dev.sh.intel.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tuesday 22 November 2016 07:30 AM, Yuanhan Liu wrote: > 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 > +1 It would help a lot of 'experimental' stuff reach a wider audience without waiting for a complete cycle of upstreaming. Though, I am not sure how would we limit the branches - or if that is even required. -- - Shreyansh