[dpdk-dev] [PATCH 0/4] libeventdev API and northbound implementation
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 +, Bruce Richardson wrote: >>> +Thomas >>> >>> On Fri, Nov 18, 2016 at 03:25:18PM +, 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
[dpdk-dev] [PATCH 0/4] libeventdev API and northbound implementation
On Sat, Nov 19, 2016 at 12:57:15AM +0530, Jerin Jacob wrote: > On Fri, Nov 18, 2016 at 04:04:29PM +, Bruce Richardson wrote: > > +Thomas > > > > On Fri, Nov 18, 2016 at 03:25:18PM +, 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
[dpdk-dev] [PATCH 0/4] libeventdev API and northbound implementation
2016-11-21 09:57, Bruce Richardson: > On Mon, Nov 21, 2016 at 10:40:50AM +0100, Thomas Monjalon wrote: > > Are you asking for a temporary tree? > > If yes, please tell its name and its committers, it will be done. > > Yes, we are asking for a new tree, but I would not assume it is > temporary - it might be, but it also might not be, given how other > threads are discussing having an increasing number of subtrees giving > pull requests. :-) > > Name: dpdk-eventdev-next Named dpdk-next-eventdev for consistency. > Committers: Bruce Richardson & Jerin Jacob Access granted. Jerin could you send me a public SSH key please?
[dpdk-dev] [PATCH 0/4] libeventdev API and northbound implementation
2016-11-19 00:57, Jerin Jacob: > On Fri, Nov 18, 2016 at 04:04:29PM +, Bruce Richardson wrote: > > On Fri, Nov 18, 2016 at 03:25:18PM +, Bruce Richardson wrote: > > > On Fri, Nov 18, 2016 at 11:14:58AM +0530, Jerin Jacob wrote: > > > > 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 Are you asking for a temporary tree? If yes, please tell its name and its committers, it will be done.
[dpdk-dev] [PATCH 0/4] libeventdev API and northbound implementation
On Mon, Nov 21, 2016 at 10:40:50AM +0100, Thomas Monjalon wrote: > 2016-11-19 00:57, Jerin Jacob: > > On Fri, Nov 18, 2016 at 04:04:29PM +, Bruce Richardson wrote: > > > On Fri, Nov 18, 2016 at 03:25:18PM +, Bruce Richardson wrote: > > > > On Fri, Nov 18, 2016 at 11:14:58AM +0530, Jerin Jacob wrote: > > > > > 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 > > Are you asking for a temporary tree? > If yes, please tell its name and its committers, it will be done. Yes, we are asking for a new tree, but I would not assume it is temporary - it might be, but it also might not be, given how other threads are discussing having an increasing number of subtrees giving pull requests. :-) Name: dpdk-eventdev-next Committers: Bruce Richardson & Jerin Jacob Thanks, /Bruce.
[dpdk-dev] [PATCH 0/4] libeventdev API and northbound implementation
On Fri, Nov 18, 2016 at 04:04:29PM +, Bruce Richardson wrote: > +Thomas > > On Fri, Nov 18, 2016 at 03:25:18PM +, 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 Jerin > > > > Regards, > > /Bruce > >
[dpdk-dev] [PATCH 0/4] libeventdev API and northbound implementation
+Thomas On Fri, Nov 18, 2016 at 03:25:18PM +, 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? > > Regards, > /Bruce >
[dpdk-dev] [PATCH 0/4] libeventdev API and northbound implementation
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
[dpdk-dev] [PATCH 0/4] libeventdev API and northbound implementation
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) TODO: 1) Example applications for pipelining, packet ingress order maintenance with ORDERED type and ATOMIC synchronization services. 2) Create user guide Jerin Jacob (4): eventdev: introduce event driven programming model eventdev: implement the northbound APIs event/skeleton: add skeleton eventdev driver app/test: unit test case for eventdev APIs MAINTAINERS|5 + app/test/Makefile |2 + app/test/test_eventdev.c | 776 +++ config/common_base | 14 + doc/api/doxy-api-index.md |1 + doc/api/doxy-api.conf |1 + drivers/Makefile |1 + drivers/event/Makefile | 36 + drivers/event/skeleton/Makefile| 55 + .../skeleton/rte_pmd_skeleton_event_version.map|4 + drivers/event/skeleton/skeleton_eventdev.c | 535 drivers/event/skeleton/skeleton_eventdev.h | 72 + lib/Makefile |1 + lib/librte_eal/common/include/rte_log.h|1 + lib/librte_eventdev/Makefile | 57 + lib/librte_eventdev/rte_eventdev.c | 1211 lib/librte_eventdev/rte_eventdev.h | 1439 lib/librte_eventdev/rte_eventdev_pmd.h | 504 +++ lib/librte_eventdev/rte_eventdev_version.map | 39 + mk/rte.app.mk |5 + 20 files changed, 4759 insertions(+) create mode 100644 app/test/test_eventdev.c create mode 100644 drivers/event/Makefile create mode 100644 drivers/event/skeleton/Makefile create mode 100644 drivers/event/skeleton/rte_pmd_skeleton_event_version.map create mode 100644 drivers/event/skeleton/skeleton_eventdev.c create mode 100644 drivers/event/skeleton/skeleton_eventdev.h create mode 100644 lib/librte_eventdev/Makefile create mode 100644 lib/librte_eventdev/rte_eventdev.c create mode 100644 lib/librte_eventdev/rte_eventdev.h create mode 100644 lib/librte_eventdev/rte_eventdev_pmd.h create mode 100644 lib/librte_eventdev/rte_eventdev_version.map -- 2.5.5
