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

[Bruce Richardson]

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?

Regards,
/Bruce