From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 42840475E for ; Thu, 17 Nov 2016 11:05:11 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga103.jf.intel.com with ESMTP; 17 Nov 2016 02:05:10 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,653,1473145200"; d="scan'208";a="902426373" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.64]) by orsmga003.jf.intel.com with SMTP; 17 Nov 2016 02:05:08 -0800 Received: by (sSMTP sendmail emulation); Thu, 17 Nov 2016 10:05:07 +0000 Date: Thu, 17 Nov 2016 10:05:07 +0000 From: Bruce Richardson To: Jerin Jacob Cc: Harry van Haaren , dev@dpdk.org Message-ID: <20161117100507.GA67928@bricha3-MOBL3.ger.corp.intel.com> References: <1479319207-130646-1-git-send-email-harry.van.haaren@intel.com> <20161116201924.GA32292@svelivela-lt.caveonetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161116201924.GA32292@svelivela-lt.caveonetworks.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] [RFC PATCH 0/7] RFC: EventDev Software PMD 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: Thu, 17 Nov 2016 10:05:12 -0000 On Thu, Nov 17, 2016 at 01:49:25AM +0530, Jerin Jacob wrote: > On Wed, Nov 16, 2016 at 06:00:00PM +0000, Harry van Haaren wrote: > > This series of RFC patches implements the libeventdev API and a software > > eventdev PMD. > > > > The implementation here is intended to enable the community to use the > > eventdev API, specifically to test if the API serves the purpose that it is > > designed to. It should be noted this is an RFC implementation, and hence > > there should be no performance expectations. > > > > An RFC for the eventdev was sent in August[1] by Jerin Jacob of Cavium, > > which introduced the core concepts of the eventdev to the community. Since > > then there has been extensive discussion[2] on the mailing list, which had > > led to various modifications to the initial proposed API. > > > > The API as presented in the first patch contains a number of changes that > > have not yet been discussed. These changes were noticed during the > > implementation of the software eventdev PMD, and were added to the API to > > enable completion of the PMD. These modifications include a statistics API > > and a dump API. For more details, please refer to the commit message of the > > patch itself. > > > > The functionality provided by each of the patches is as follows: > > 1: Add eventdev API and library infrastructure > > 2: Enable compilation of library > > 3: Add software eventdev PMD > > 4: Enable compilation of PMD > > 5: Add test code > > 6: Enable test code compilation > > 7: Sample application demonstrating basic usage > > > > This breakdown of the patchset hopefully enables the community to experiment > > with the eventdev API, and allows us all to gain first-hand experience in > > using the eventdev API. Note also that this patchset has not passed > > checkpatch testing just yet - will fix for v2 :) > > > > As next steps I see value in discussing the proposed changes included in > > this version of the header file, while welcoming feedback from the community > > on the API in general too. > > Thanks. Harry. > > Even I was writing the similar stuff.I took a bit different approach on > the common code side, where I was trying to have fat common code( > lib/librte_eventdev/rte_eventdev.c) with start/stop support for the > slow-path code. I will post the implementation in few days and then we > can work on a converged solution. Looking forward to seeing this. Hopefully some of our code can be reused on your side too, maybe the registration and args parsing bits, perhaps. > > Following sections of code does not have any overlap at all. > test/eventdev: unit and functional tests > event/sw: software eventdev implementation > examples/eventdev_pipeline: adding example > > Some questions and initial feedback > 1) I thought RTE_EVENT_OP_DROP and rte_event_release() are same ? No ? They should be largely equivalent, just that the DROP op can be done as part of a burst. If they are not, it could be a bug in our implementation, as it's still an early draft using this eventdev API. > 2) device stats API can be based on capability, HW implementations may not > support all the stats Yes, this is something we were thinking about. It would be nice if we could at least come up with a common set of stats - maybe even ones tracked at an eventdev API level, e.g. nb enqueues/dequeues. As well as that, we think the idea of an xstats API, like in ethdev, might work well. For our software implementation, having visibility into the scheduler behaviour can be important, so we'd like a way to report out things like internal queue depths etc. > 3) From the HW implementation perspective, eventdev_pipeline application > needs to have a lot of changes.I will post the comments in coming days > and we can work together on the converged solution. Yes, please do. I expect we'll need a good set of guidelines in order to allow people to write truly portable apps using this API. Thanks for the feedback. /Bruce > > Jerin > >