[dpdk-dev] [RFC PATCH 0/7] RFC: EventDev Software PMD

[Bruce Richardson]

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
> 
>