From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [PATCH v4 3/4] eventdev: Add eventdev ethernet Rx adapter Date: Mon, 2 Oct 2017 16:09:56 +0530 Message-ID: <20171002103955.GA11011@jerin> References: <1506028634-22998-1-git-send-email-nikhil.rao@intel.com> <1506028634-22998-4-git-send-email-nikhil.rao@intel.com> <20170922091032.GA5895@jerin> <92c090c8-b024-dc9f-6d76-59d4b44ab3f5@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: bruce.richardson@intel.com, gage.eads@intel.com, dev@dpdk.org, thomas@monjalon.net, harry.van.haaren@intel.com, hemant.agrawal@nxp.com, nipun.gupta@nxp.com, narender.vangati@intel.com, erik.g.carrillo@intel.com, abhinandan.gujjar@intel.com, santosh.shukla@caviumnetworks.com To: "Rao, Nikhil" Return-path: Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0056.outbound.protection.outlook.com [104.47.41.56]) by dpdk.org (Postfix) with ESMTP id 4C21B1B1FD for ; Mon, 2 Oct 2017 12:40:21 +0200 (CEST) Content-Disposition: inline In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" -----Original Message----- > Date: Mon, 2 Oct 2017 15:58:56 +0530 > From: "Rao, Nikhil" > To: Jerin Jacob > CC: bruce.richardson@intel.com, gage.eads@intel.com, dev@dpdk.org, > thomas@monjalon.net, harry.van.haaren@intel.com, hemant.agrawal@nxp.com, > nipun.gupta@nxp.com, narender.vangati@intel.com, > erik.g.carrillo@intel.com, abhinandan.gujjar@intel.com, > santosh.shukla@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 */