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
