[dpdk-dev] [PATCH v4 3/4] eventdev: Add eventdev ethernet Rx adapter
Rao, Nikhil
nikhil.rao at intel.com
Mon Oct 2 12:28:56 CEST 2017
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
More information about the dev
mailing list