[dpdk-dev,v4,3/4] eventdev: Add eventdev ethernet Rx adapter

Message ID 20171002103955.GA11011@jerin (mailing list archive)
State Not Applicable, archived
Headers

Checks

Context Check Description
ci/checkpatch warning coding style issues
ci/Intel-compilation success Compilation OK

Commit Message

Jerin Jacob Oct. 2, 2017, 10:39 a.m. UTC
  -----Original Message-----
> Date: Mon, 2 Oct 2017 15:58:56 +0530
> From: "Rao, Nikhil" <nikhil.rao@intel.com>
> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> 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
> 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
  

Comments

Rao, Nikhil Oct. 5, 2017, 8:54 a.m. UTC | #1
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.rao@intel.com>
>> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
>> 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
>> 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
  

Patch

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 */