From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id B38727CBD for ; Thu, 5 Oct 2017 10:54:36 +0200 (CEST) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga105.jf.intel.com with ESMTP; 05 Oct 2017 01:54:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,480,1500966000"; d="scan'208";a="159124930" Received: from nikhilr-mobl.amr.corp.intel.com (HELO [10.106.152.123]) ([10.106.152.123]) by fmsmga005.fm.intel.com with ESMTP; 05 Oct 2017 01:54:32 -0700 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 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> <20171002103955.GA11011@jerin> From: "Rao, Nikhil" Message-ID: Date: Thu, 5 Oct 2017 14:24:31 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171002103955.GA11011@jerin> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v4 3/4] eventdev: Add eventdev ethernet Rx adapter X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Oct 2017 08:54:37 -0000 On 10/2/2017 4:09 PM, Jerin Jacob wrote: > -----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 */ > The event source is really RTE_EVENT_TYPE_CPU here, but is the assumption that the RTE_EVENT_TYPE_CPU name space is owned by the application (it's actions are driven by a combination of event type and event sub type) and extending the event source count is the only option here. Nikhil