[dpdk-dev] [PATCH] doc: add eventdev library to programmers guide

Van Haaren, Harry harry.van.haaren at intel.com
Thu Mar 30 17:59:26 CEST 2017


> From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com]
> Sent: Thursday, March 30, 2017 2:37 PM
> To: Van Haaren, Harry <harry.van.haaren at intel.com>
> Cc: dev at dpdk.org; thomas.monjalon at 6wind.com; hemant.agrawal at nxp.com; Richardson, Bruce
> <bruce.richardson at intel.com>
> Subject: Re: [dpdk-dev] [PATCH] doc: add eventdev library to programmers guide
> 
> On Wed, Mar 15, 2017 at 05:21:18PM +0000, Harry van Haaren wrote:
> > This commit adds an entry in the programmers guide
> > explaining the eventdev library.
> >
> > The rte_event struct, queues and ports are explained.
> > An API walktrough of a simple two stage atomic pipeline
> > provides the reader with a step by step overview of the
> > expected usage of the Eventdev API.
> 
> 
> Thanks Harry for writing this document.
> Overall it looks good.

Thanks for the thanks!


> I have a few thoughts on this document and next steps of eventdev:
> 
> 1) Need more use cases and associated example applications
> 
> The initial version talks only about queue based event pipelining,
> I think, we need to add another use case like following in the eventdev
> programmers guide with associated example applications.
> a) automatic multicore scaling
> b) dynamic load balancing,
> c) flow based pipelining
> d) packet ingress order maintenance
> e) synchronization services.

Agreed some sample apps would ease starting to use the eventdev API.


> 2) ethdev integration is pending.
> 
> There are some ethdev(NIC) HW features associated with HW eventdev
> implementations. For example,  The given example in the programming
> guide has dedicated Rx and Tx cores, In HW ethdev and HW eventdev case,
> 
> - NIC HW can produce and inject the events to eventdev. No need for
>   additional Rx core push the data to eventdev on those HW
> - In Some NIC HW without SW lock, multiple cores can access the same tx queue
>   hence the need for additional TX core may not valid on those HW.

Right - these details will need to be worked out as the PMDs are developed.
 

> IMO, Addressing all the use case with generic example application and
> ethdev integration with eventdev would call for minor changes in the
> eventdev API and the programmer guide content.
 
Yes a generic sample app would be great, I'll post the sample app that we've been using for testing the SW PMD to patchwork in the next weeks if possible. It is a multi-stage pipeline based application, similar to that described in the prog-guide documentation.


> Considering the above points, I would like to share the current
> eventdev status and propose the next step for eventdev.
> 
> Current eventdev status:
> 1) Eventdev specification more or less complete
> 2) Two eventdev driver implementations are ready(completed the review) along
> with unit test cases.
> a) An eventdev SW driver from Intel
> b) An eventdev HW driver from Cavium
> 
> Pending work:
> 1) More generic example applications with additional eventdev uses case
> backed by programming guide.
> IMO, programming guide will be complete only with generic example
> applications.IMHO, we can add the programming guide once we have generic examples
> 2) Minor change in eventdev specification to accommodate ethdev integration
> and example generic application with ethdev and eventdev for packet
> forwarding.
> 
> If noone is working this, I am planning to work on item 1 and 2 to
> complete eventdev work.

Generic sample apps that work with all PMDs would be great, as above I'll share the example pipeline app asap.
Regarding API changes, yes we can deal with them as they arise during implementation.


> Based on the above status, I would like to merge eventdev to DPDK
> v17.05 with EXPERIMENTAL tag and address pending work in v17.08 and
> remove the EXPERIMENTAL tag.
> 
> Thomas and all,
> 
> Thoughts ?
> 
> NOTE:
> 
> Keeping the EXPERIMENTAL status to allow minor change in the API without
> ABI issue when we address the pending work and I guess NXP eventdev also
> lined up for v17.08 and they may need a minor change in the API


This seems a good suggestion to me, as it enables us to move quickly in terms of API/ABI (if required for new/updated PMDs) but still ensures that the eventdev becomes available to DPDK mainline users too.


No objections to this approach here, -Harry


More information about the dev mailing list