On 10/2/2017 4:09 PM, Jerin Jacob wrote:
-----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 */
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
