From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id C151623A for ; Mon, 25 Sep 2017 04:59:16 +0200 (CEST) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Sep 2017 19:59:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,434,1500966000"; d="scan'208";a="152873142" Received: from unknown (HELO [10.106.152.14]) ([10.106.152.14]) by orsmga005.jf.intel.com with ESMTP; 24 Sep 2017 19:59:11 -0700 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 References: <1506028634-22998-1-git-send-email-nikhil.rao@intel.com> <1506028634-22998-4-git-send-email-nikhil.rao@intel.com> <20170922091032.GA5895@jerin> Message-ID: <92c090c8-b024-dc9f-6d76-59d4b44ab3f5@intel.com> Date: Mon, 25 Sep 2017 08:29:10 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Mon, 25 Sep 2017 02:59:17 -0000 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