-----Original Message----- > Date: Mon, 2 Oct 2017 15:58:56 +0530 > From: "Rao, Nikhil" <nikhil....@intel.com> > To: Jerin Jacob <jerin.ja...@caviumnetworks.com> > CC: bruce.richard...@intel.com, gage.e...@intel.com, dev@dpdk.org, > tho...@monjalon.net, harry.van.haa...@intel.com, hemant.agra...@nxp.com, > nipun.gu...@nxp.com, narender.vang...@intel.com, > erik.g.carri...@intel.com, abhinandan.guj...@intel.com, > santosh.shu...@caviumnetworks.com > Subject: Re: [PATCH v4 3/4] eventdev: Add eventdev ethernet Rx adapter > User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 > Thunderbird/52.3.0 > > On 9/25/2017 8:29 AM, Rao, Nikhil wrote: > > On 9/24/2017 11:46 PM, Rao, Nikhil wrote: > > > On 9/22/2017 2:40 PM, Jerin Jacob wrote: > > > > > > > When we worked on a prototype, we figured out that we need a > > > > separate event type > > > > for RX adapter. Probably RTE_EVENT_TYPE_ETHDEV_RX_ADAPTER? > > > > The Reason is: > > > > - In the HW based Rx adapter case, the packet are coming > > > > directly to eventdev once it is configured. > > > > - So on a HW implementation of the event dequeue(), CPU needs to > > > > convert HW specific > > > > metadata to mbuf > > > > - The event dequeue() is used in two cases > > > > a) octeontx eventdev driver used with any external NIC > > > > b) octeontx eventdev driver used with integrated NIC(without service > > > > core to inject the packet) > > > > We need some identifier to understand case (a) and (b).So, in > > > > dequeue(), if the > > > > packet is from RTE_EVENT_TYPE_ETHDEV then we can do "HW specific > > > > metadata" to mbuf > > > > conversion and in another case (!RTE_EVENT_TYPE_ETHDEV) result > > > > in no mbuf > > > > conversion. > > > > > > > > Application can check if it is an Ethernet type event by > > > > ev.event_type == RTE_EVENT_TYPE_ETHDEV || ev.event_type == > > > > RTE_EVENT_TYPE_ETHDEV_RX_ADAPTER > > > > > > > > > > As per my understanding, the case (a) uses an in built port > > > Is it possible for the eventdev PMD to do the conversion based off > > > the eventdev port ? > > > > > > > I realized the dequeue wouldn't have knowledge of the port the event was > > injected from, the application shouldn't have to see the difference > > between case (a) & (b). > > > > Would it be possible to use the impl_opaque field within struct rte_event ? > > > > Nikhil > > Hi Jerin, > > Any further thoughts on this ?
impl_opaque field could be one option. But I think, NXP driver is using it for internal operation. So overriding it from Rx adapter will cause issue. How about adding new event type? So it gets a new name space so no collision. ➜ [master][dpdk-next-eventdev] $ git diff diff --git a/lib/librte_eventdev/rte_eventdev.h b/lib/librte_eventdev/rte_eventdev.h index ec7aabd9a..b33423c7e 100644 --- a/lib/librte_eventdev/rte_eventdev.h +++ b/lib/librte_eventdev/rte_eventdev.h @@ -878,6 +878,8 @@ rte_event_dev_close(uint8_t dev_id); /**< The event generated from cpu for pipelining. * Application may use *sub_event_type* to further classify the event */ +#define RTE_EVENT_TYPE_ETHDEV_ADAPTER 0x4 +/**< The event generated from ethdev Rx adapter */ #define RTE_EVENT_TYPE_MAX 0x10 /**< Maximum number of event types */
