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 ?
Nikhil
