[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