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.
