[dpdk-dev] [PATCH 0/4] libeventdev API and northbound implementation

Shreyansh Jain shreyansh.jain at nxp.com
Tue Nov 22 10:05:20 CET 2016


On Tuesday 22 November 2016 07:30 AM, Yuanhan Liu wrote:
> On Sat, Nov 19, 2016 at 12:57:15AM +0530, Jerin Jacob wrote:
>> On Fri, Nov 18, 2016 at 04:04:29PM +0000, Bruce Richardson wrote:
>>> +Thomas
>>>
>>> On Fri, Nov 18, 2016 at 03:25:18PM +0000, Bruce Richardson wrote:
>>>> On Fri, Nov 18, 2016 at 11:14:58AM +0530, Jerin Jacob wrote:
>>>>> As previously discussed in RFC v1 [1], RFC v2 [2], with changes
>>>>> described in [3] (also pasted below), here is the first non-draft series
>>>>> for this new API.
>>>>>
>>>>> [1] http://dpdk.org/ml/archives/dev/2016-August/045181.html
>>>>> [2] http://dpdk.org/ml/archives/dev/2016-October/048592.html
>>>>> [3] http://dpdk.org/ml/archives/dev/2016-October/048196.html
>>>>>
>>>>> Changes since RFC v2:
>>>>>
>>>>> - Updated the documentation to define the need for this library[Jerin]
>>>>> - Added RTE_EVENT_QUEUE_CFG_*_ONLY configuration parameters in
>>>>>   struct rte_event_queue_conf to enable optimized sw implementation [Bruce]
>>>>> - Introduced RTE_EVENT_OP* ops [Bruce]
>>>>> - Added nb_event_queue_flows,nb_event_port_dequeue_depth, nb_event_port_enqueue_depth
>>>>>   in rte_event_dev_configure() like ethdev and crypto library[Jerin]
>>>>> - Removed rte_event_release() and replaced with RTE_EVENT_OP_RELEASE ops to
>>>>>   reduce fast path APIs and it is redundant too[Jerin]
>>>>> - In the view of better application portability, Removed pin_event
>>>>>   from rte_event_enqueue as it is just hint and Intel/NXP can not support it[Jerin]
>>>>> - Added rte_event_port_links_get()[Jerin]
>>>>> - Added rte_event_dev_dump[Harry]
>>>>>
>>>>> Notes:
>>>>>
>>>>> - This patch set is check-patch clean with an exception that
>>>>> 02/04 has one WARNING:MACRO_WITH_FLOW_CONTROL
>>>>> - Looking forward to getting additional maintainers for libeventdev
>>>>>
>>>>>
>>>>> Possible next steps:
>>>>> 1) Review this patch set
>>>>> 2) Integrate Intel's SW driver[http://dpdk.org/dev/patchwork/patch/17049/]
>>>>> 3) Review proposed examples/eventdev_pipeline application[http://dpdk.org/dev/patchwork/patch/17053/]
>>>>> 4) Review proposed functional tests[http://dpdk.org/dev/patchwork/patch/17051/]
>>>>> 5) Cavium's HW based eventdev driver
>>>>>
>>>>> I am planning to work on (3),(4) and (5)
>>>>>
>>>> Thanks Jerin,
>>>>
>>>> we'll review and get back to you with any comments or feedback (1), and
>>>> obviously start working on item (2) also! :-)
>>>>
>>>> I'm also wonder whether we should have a staging tree for this work to
>>>> make interaction between us easier. Although this may not be
>>>> finalised enough for 17.02 release, do you think having an
>>>> dpdk-eventdev-next tree would be a help? My thinking is that once we get
>>>> the eventdev library itself in reasonable shape following our review, we
>>>> could commit that and make any changes thereafter as new patches, rather
>>>> than constantly respinning the same set. It also gives us a clean git
>>>> tree to base the respective driver implementations on from our two sides.
>>>>
>>>> Thomas, any thoughts here on your end - or from anyone else?
>>
>> I was thinking more or less along the same lines. To avoid re-spinning the
>> same set, it is better to have libeventdev library mark as EXPERIMENTAL
>> and commit it somewhere on dpdk-eventdev-next or main tree
>>
>> I think, EXPERIMENTAL status can be changed only when
>> - At least two event drivers available
>> - Functional test applications fine with at least two drivers
>> - Portable example application to showcase the features of the library
>> - eventdev integration with another dpdk subsystem such as ethdev
>
> I'm wondering maybe we could have a staging tree, for all features like
> this one (and one branch for each feature)?
>
> 	--yliu
>

+1

It would help a lot of 'experimental' stuff reach a wider audience 
without waiting for a complete cycle of upstreaming.
Though, I am not sure how would we limit the branches - or if that is 
even required.

-- 
-
Shreyansh


More information about the dev mailing list