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

Jerin Jacob jerin.jacob at caviumnetworks.com
Fri Mar 31 15:31:17 CEST 2017


On Fri, Mar 31, 2017 at 02:43:15PM +0200, Thomas Monjalon wrote:
> 2017-03-30 19:06, Jerin Jacob:
> > 2) ethdev integration is pending.
> 
> What is pending exactly?

As a standalone library, Nothing is pending in eventdev.

There are some HW features in the NIC side in some Hardwares that helps
in offloading eventdev related work in NIC. For example,

In the RX side, Some actor is required to inject the events/packets to
eventdev. Some Hardware is capable of offloading that work in NIC.
if that HW feature is not available then core can do the same.

On the TX side, N cores can send the packets to the same TX queue
WITHOUT SW lock. This helps in proper scaling, If that HW feature is not available
in NIC side then core can decide to bind only one tx queue per core.

On the RX side, I don't expect any change in ethdev API.
On the TX side, We may need to have some capability to expose the lock-less
features(I haven't thought about the abstraction details fully).

What I meant by pending here is that, Some future work is required to
enable, abstracting those HW difference and to have portable example
eventdev applications.

> 
> [...]
> > 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
> 
> Yes, generally speaking, it is a good idea to put the experimental tag
> for the first release of an API.


More information about the dev mailing list