Message ID | 20241030212304.104180-1-konstantin.ananyev@huawei.com (mailing list archive) |
---|---|
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id EA16245B82; Wed, 30 Oct 2024 21:32:38 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D8C46432FA; Wed, 30 Oct 2024 21:32:38 +0100 (CET) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by mails.dpdk.org (Postfix) with ESMTP id 701E842F2B for <dev@dpdk.org>; Wed, 30 Oct 2024 21:32:36 +0100 (CET) Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4XdzKw51S9z6K5mS; Thu, 31 Oct 2024 04:31:16 +0800 (CST) Received: from frapeml500007.china.huawei.com (unknown [7.182.85.172]) by mail.maildlp.com (Postfix) with ESMTPS id B9BEC140B67; Thu, 31 Oct 2024 04:32:35 +0800 (CST) Received: from localhost.localdomain (10.220.239.45) by frapeml500007.china.huawei.com (7.182.85.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Wed, 30 Oct 2024 21:32:35 +0100 From: Konstantin Ananyev <konstantin.ananyev@huawei.com> To: <dev@dpdk.org> CC: <honnappa.nagarahalli@arm.com>, <jerinj@marvell.com>, <hemant.agrawal@nxp.com>, <bruce.richardson@intel.com>, <drc@linux.vnet.ibm.com>, <ruifeng.wang@arm.com>, <mb@smartsharesystems.com>, <eimear.morrissey@huawei.com>, <stephen@networkplumber.org> Subject: [PATCH v7 0/7] Stage-Ordered API and other extensions for ring library Date: Wed, 30 Oct 2024 17:22:57 -0400 Message-ID: <20241030212304.104180-1-konstantin.ananyev@huawei.com> X-Mailer: git-send-email 2.35.3 In-Reply-To: <20241021174745.1843-1-konstantin.ananyev@huawei.com> References: <20241021174745.1843-1-konstantin.ananyev@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.220.239.45] X-ClientProxiedBy: frapeml100006.china.huawei.com (7.182.85.201) To frapeml500007.china.huawei.com (7.182.85.172) X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org |
Series |
Stage-Ordered API and other extensions for ring library
|
|
Message
Konstantin Ananyev
Oct. 30, 2024, 9:22 p.m. UTC
Testing coverage (passed): x86_64, i686, PPC, ARM Would like to express my gratitude to all community members who helped me with testing it on different platforms, in particular: David Christensen <drc@linux.ibm.com> Cody Cheng <ccheng@iol.unh.edu> Patrick Robb <probb@iol.unh.edu> Phanendra Vukkisala <pvukkisala@marvell.com> Chengwen Feng <fengchengwen@huawei.com> v6 -> v7 - updated Programmer Guide (Jerin, Morten, Stephen) - fix some functions in public headers without comments (Morten) - update debug checks, added new macro for that: RTE_SORING_DEBUG (disabled by default). v5 -> v6 - fix problem with ring_stress_autotest (Phanendra) - added more checks and debug output v4 -> v5 - fix public API/doc comments from Jerin - update devtools/build-dict.sh (Stephen) - fix MSVC warnings - introduce new test-suite for meson (stress) with ring_stress_autotest and soring_stress_autotest in it - enhance error report in tests - reorder some sync code in soring and add extra checks (for better debuggability) v3 -> v4: - fix compilation/doxygen complains (attempt #2) - updated release notes v2 -> v3: - fix compilation/doxygen complains - dropped patch: "examples/l3fwd: make ACL work in pipeline and eventdev modes": [2] As was mentioned in the patch desctiption it was way too big, controversial and incomplete. If the community is ok to introduce pipeline model into the l3fwd, then it is propbably worth to be a separate patch series. v1 -> v2: - rename 'elmst/objst' to 'meta' (Morten) - introduce new data-path APIs set: one with both meta{} and objs[], second with just objs[] (Morten) - split data-path APIs into burst/bulk flavours (same as rte_ring) - added dump function for te_soring and improved dump() for rte_ring. - dropped patch: " ring: minimize reads of the counterpart cache-line" - no performance gain observed - actually it does change behavior of conventional rte_ring enqueue/dequeue APIs - it could return available/free less then actually exist in the ring. As in some other libs we reliy on that information - it will introduce problems. The main aim of these series is to extend ring library with new API that allows user to create/use Staged-Ordered-Ring (SORING) abstraction. In addition to that there are few other patches that serve different purposes: - first two patches are just code reordering to de-duplicate and generalize existing rte_ring code. - patch #3 extends rte_ring_dump() to correctly print head/tail metadata for different sync modes. - next two patches introduce SORING API into the ring library and provide UT for it. SORING overview =============== Staged-Ordered-Ring (SORING) provides a SW abstraction for 'ordered' queues with multiple processing 'stages'. It is based on conventional DPDK rte_ring, re-uses many of its concepts, and even substantial part of its code. It can be viewed as an 'extension' of rte_ring functionality. In particular, main SORING properties: - circular ring buffer with fixed size objects - producer, consumer plus multiple processing stages in between. - allows to split objects processing into multiple stages. - objects remain in the same ring while moving from one stage to the other, initial order is preserved, no extra copying needed. - preserves the ingress order of objects within the queue across multiple stages - each stage (and producer/consumer) can be served by single and/or multiple threads. - number of stages, size and number of objects in the ring are configurable at ring initialization time. Data-path API provides four main operations: - enqueue/dequeue works in the same manner as for conventional rte_ring, all rte_ring synchronization types are supported. - acquire/release - for each stage there is an acquire (start) and release (finish) operation. After some objects are 'acquired' - given thread can safely assume that it has exclusive ownership of these objects till it will invoke 'release' for them. After 'release', objects can be 'acquired' by next stage and/or dequeued by the consumer (in case of last stage). Expected use-case: applications that uses pipeline model (probably with multiple stages) for packet processing, when preserving incoming packet order is important. The concept of ‘ring with stages’ is similar to DPDK OPDL eventdev PMD [1], but the internals are different. In particular, SORING maintains internal array of 'states' for each element in the ring that is shared by all threads/processes that access the ring. That allows 'release' to avoid excessive waits on the tail value and helps to improve performancei and scalability. In terms of performance, with our measurements rte_soring and conventional rte_ring provide nearly identical numbers. As an example, on our SUT: Intel ICX CPU @ 2.00GHz, l3fwd (--lookup=acl) in pipeline mode [2] both rte_ring and rte_soring reach ~20Mpps for single I/O lcore and same number of worker lcores. [1] https://www.dpdk.org/wp-content/uploads/sites/35/2018/06/DPDK-China2017-Ma-OPDL.pdf [2] https://patchwork.dpdk.org/project/dpdk/patch/20240906131348.804-7-konstantin.v.ananyev@yandex.ru/ Eimear Morrissey (1): ring: make dump function more verbose Konstantin Ananyev (6): test/ring: fix failure with custom number of lcores ring: common functions for 'move head' ops ring: make copying functions generic ring/soring: introduce Staged Ordered Ring app/test: add unit tests for soring API test: add stress test suite .mailmap | 1 + app/test/meson.build | 3 + app/test/suites/meson.build | 10 + app/test/test.h | 1 + app/test/test_ring_stress.c | 2 +- app/test/test_ring_stress_impl.h | 3 +- app/test/test_soring.c | 442 ++++++++++++ app/test/test_soring_mt_stress.c | 40 ++ app/test/test_soring_stress.c | 48 ++ app/test/test_soring_stress.h | 35 + app/test/test_soring_stress_impl.h | 834 ++++++++++++++++++++++ devtools/build-dict.sh | 1 + doc/api/doxy-api-index.md | 1 + doc/guides/prog_guide/img/soring-pic1.svg | 635 ++++++++++++++++ doc/guides/prog_guide/ring_lib.rst | 202 ++++++ doc/guides/rel_notes/release_24_11.rst | 8 + lib/ring/meson.build | 4 +- lib/ring/rte_ring.c | 87 ++- lib/ring/rte_ring.h | 15 + lib/ring/rte_ring_c11_pvt.h | 156 ++-- lib/ring/rte_ring_elem_pvt.h | 181 +++-- lib/ring/rte_ring_generic_pvt.h | 143 ++-- lib/ring/rte_ring_hts_elem_pvt.h | 107 ++- lib/ring/rte_ring_rts_elem_pvt.h | 107 ++- lib/ring/rte_soring.c | 198 +++++ lib/ring/rte_soring.h | 556 +++++++++++++++ lib/ring/soring.c | 613 ++++++++++++++++ lib/ring/soring.h | 138 ++++ lib/ring/version.map | 26 + 29 files changed, 4217 insertions(+), 380 deletions(-) create mode 100644 app/test/test_soring.c create mode 100644 app/test/test_soring_mt_stress.c create mode 100644 app/test/test_soring_stress.c create mode 100644 app/test/test_soring_stress.h create mode 100644 app/test/test_soring_stress_impl.h create mode 100644 doc/guides/prog_guide/img/soring-pic1.svg create mode 100644 lib/ring/rte_soring.c create mode 100644 lib/ring/rte_soring.h create mode 100644 lib/ring/soring.c create mode 100644 lib/ring/soring.h
Comments
Hi everyone, Does anyone have any extra comments for that series? If not, would it be possible to consider it for 24.11 rc2? Thomas and David what are your thoughts on that subject? Thanks Konstantin > -----Original Message----- > From: Konstantin Ananyev <konstantin.ananyev@huawei.com> > Sent: Wednesday, October 30, 2024 9:23 PM > To: dev@dpdk.org > Cc: honnappa.nagarahalli@arm.com; jerinj@marvell.com; hemant.agrawal@nxp.com; bruce.richardson@intel.com; > drc@linux.vnet.ibm.com; ruifeng.wang@arm.com; mb@smartsharesystems.com; Eimear Morrissey > <eimear.morrissey@huawei.com>; stephen@networkplumber.org > Subject: [PATCH v7 0/7] Stage-Ordered API and other extensions for ring library > > Testing coverage (passed): > x86_64, i686, PPC, ARM > > Would like to express my gratitude to all community members who helped me > with testing it on different platforms, in particular: > David Christensen <drc@linux.ibm.com> > Cody Cheng <ccheng@iol.unh.edu> > Patrick Robb <probb@iol.unh.edu> > Phanendra Vukkisala <pvukkisala@marvell.com> > Chengwen Feng <fengchengwen@huawei.com> > > v6 -> v7 > - updated Programmer Guide (Jerin, Morten, Stephen) > - fix some functions in public headers without comments (Morten) > - update debug checks, added new macro for that: RTE_SORING_DEBUG > (disabled by default). > > v5 -> v6 > - fix problem with ring_stress_autotest (Phanendra) > - added more checks and debug output > > v4 -> v5 > - fix public API/doc comments from Jerin > - update devtools/build-dict.sh (Stephen) > - fix MSVC warnings > - introduce new test-suite for meson (stress) with > ring_stress_autotest and soring_stress_autotest in it > - enhance error report in tests > - reorder some sync code in soring and add extra checks > (for better debuggability) > > v3 -> v4: > - fix compilation/doxygen complains (attempt #2) > - updated release notes > > v2 -> v3: > - fix compilation/doxygen complains > - dropped patch: > "examples/l3fwd: make ACL work in pipeline and eventdev modes": [2] > As was mentioned in the patch desctiption it was way too big, > controversial and incomplete. If the community is ok to introduce > pipeline model into the l3fwd, then it is propbably worth to be > a separate patch series. > > v1 -> v2: > - rename 'elmst/objst' to 'meta' (Morten) > - introduce new data-path APIs set: one with both meta{} and objs[], > second with just objs[] (Morten) > - split data-path APIs into burst/bulk flavours (same as rte_ring) > - added dump function for te_soring and improved dump() for rte_ring. > - dropped patch: > " ring: minimize reads of the counterpart cache-line" > - no performance gain observed > - actually it does change behavior of conventional rte_ring > enqueue/dequeue APIs - > it could return available/free less then actually exist in the ring. > As in some other libs we reliy on that information - it will > introduce problems. > > The main aim of these series is to extend ring library with > new API that allows user to create/use Staged-Ordered-Ring (SORING) > abstraction. In addition to that there are few other patches that serve > different purposes: > - first two patches are just code reordering to de-duplicate > and generalize existing rte_ring code. > - patch #3 extends rte_ring_dump() to correctly print head/tail metadata > for different sync modes. > - next two patches introduce SORING API into the ring library and > provide UT for it. > > SORING overview > =============== > Staged-Ordered-Ring (SORING) provides a SW abstraction for 'ordered' queues > with multiple processing 'stages'. It is based on conventional DPDK > rte_ring, re-uses many of its concepts, and even substantial part of > its code. > It can be viewed as an 'extension' of rte_ring functionality. > In particular, main SORING properties: > - circular ring buffer with fixed size objects > - producer, consumer plus multiple processing stages in between. > - allows to split objects processing into multiple stages. > - objects remain in the same ring while moving from one stage to the other, > initial order is preserved, no extra copying needed. > - preserves the ingress order of objects within the queue across multiple > stages > - each stage (and producer/consumer) can be served by single and/or > multiple threads. > > - number of stages, size and number of objects in the ring are > configurable at ring initialization time. > > Data-path API provides four main operations: > - enqueue/dequeue works in the same manner as for conventional rte_ring, > all rte_ring synchronization types are supported. > - acquire/release - for each stage there is an acquire (start) and > release (finish) operation. After some objects are 'acquired' - > given thread can safely assume that it has exclusive ownership of > these objects till it will invoke 'release' for them. > After 'release', objects can be 'acquired' by next stage and/or dequeued > by the consumer (in case of last stage). > > Expected use-case: applications that uses pipeline model > (probably with multiple stages) for packet processing, when preserving > incoming packet order is important. > > The concept of ‘ring with stages’ is similar to DPDK OPDL eventdev PMD [1], > but the internals are different. > In particular, SORING maintains internal array of 'states' for each element > in the ring that is shared by all threads/processes that access the ring. > That allows 'release' to avoid excessive waits on the tail value and helps > to improve performancei and scalability. > In terms of performance, with our measurements rte_soring and > conventional rte_ring provide nearly identical numbers. > As an example, on our SUT: Intel ICX CPU @ 2.00GHz, > l3fwd (--lookup=acl) in pipeline mode [2] both > rte_ring and rte_soring reach ~20Mpps for single I/O lcore and same > number of worker lcores. > > [1] https://www.dpdk.org/wp-content/uploads/sites/35/2018/06/DPDK-China2017-Ma-OPDL.pdf > [2] https://patchwork.dpdk.org/project/dpdk/patch/20240906131348.804-7-konstantin.v.ananyev@yandex.ru/ > > Eimear Morrissey (1): > ring: make dump function more verbose > > Konstantin Ananyev (6): > test/ring: fix failure with custom number of lcores > ring: common functions for 'move head' ops > ring: make copying functions generic > ring/soring: introduce Staged Ordered Ring > app/test: add unit tests for soring API > test: add stress test suite > > .mailmap | 1 + > app/test/meson.build | 3 + > app/test/suites/meson.build | 10 + > app/test/test.h | 1 + > app/test/test_ring_stress.c | 2 +- > app/test/test_ring_stress_impl.h | 3 +- > app/test/test_soring.c | 442 ++++++++++++ > app/test/test_soring_mt_stress.c | 40 ++ > app/test/test_soring_stress.c | 48 ++ > app/test/test_soring_stress.h | 35 + > app/test/test_soring_stress_impl.h | 834 ++++++++++++++++++++++ > devtools/build-dict.sh | 1 + > doc/api/doxy-api-index.md | 1 + > doc/guides/prog_guide/img/soring-pic1.svg | 635 ++++++++++++++++ > doc/guides/prog_guide/ring_lib.rst | 202 ++++++ > doc/guides/rel_notes/release_24_11.rst | 8 + > lib/ring/meson.build | 4 +- > lib/ring/rte_ring.c | 87 ++- > lib/ring/rte_ring.h | 15 + > lib/ring/rte_ring_c11_pvt.h | 156 ++-- > lib/ring/rte_ring_elem_pvt.h | 181 +++-- > lib/ring/rte_ring_generic_pvt.h | 143 ++-- > lib/ring/rte_ring_hts_elem_pvt.h | 107 ++- > lib/ring/rte_ring_rts_elem_pvt.h | 107 ++- > lib/ring/rte_soring.c | 198 +++++ > lib/ring/rte_soring.h | 556 +++++++++++++++ > lib/ring/soring.c | 613 ++++++++++++++++ > lib/ring/soring.h | 138 ++++ > lib/ring/version.map | 26 + > 29 files changed, 4217 insertions(+), 380 deletions(-) > create mode 100644 app/test/test_soring.c > create mode 100644 app/test/test_soring_mt_stress.c > create mode 100644 app/test/test_soring_stress.c > create mode 100644 app/test/test_soring_stress.h > create mode 100644 app/test/test_soring_stress_impl.h > create mode 100644 doc/guides/prog_guide/img/soring-pic1.svg > create mode 100644 lib/ring/rte_soring.c > create mode 100644 lib/ring/rte_soring.h > create mode 100644 lib/ring/soring.c > create mode 100644 lib/ring/soring.h > > -- > 2.35.3
On Wed, 30 Oct 2024 17:22:57 -0400 Konstantin Ananyev <konstantin.ananyev@huawei.com> wrote: > Testing coverage (passed): > x86_64, i686, PPC, ARM > > Would like to express my gratitude to all community members who helped me > with testing it on different platforms, in particular: > David Christensen <drc@linux.ibm.com> > Cody Cheng <ccheng@iol.unh.edu> > Patrick Robb <probb@iol.unh.edu> > Phanendra Vukkisala <pvukkisala@marvell.com> > Chengwen Feng <fengchengwen@huawei.com> > > v6 -> v7 > - updated Programmer Guide (Jerin, Morten, Stephen) > - fix some functions in public headers without comments (Morten) > - update debug checks, added new macro for that: RTE_SORING_DEBUG > (disabled by default). > > v5 -> v6 > - fix problem with ring_stress_autotest (Phanendra) > - added more checks and debug output > > v4 -> v5 > - fix public API/doc comments from Jerin > - update devtools/build-dict.sh (Stephen) > - fix MSVC warnings > - introduce new test-suite for meson (stress) with > ring_stress_autotest and soring_stress_autotest in it > - enhance error report in tests > - reorder some sync code in soring and add extra checks > (for better debuggability) > > v3 -> v4: > - fix compilation/doxygen complains (attempt #2) > - updated release notes > > v2 -> v3: > - fix compilation/doxygen complains > - dropped patch: > "examples/l3fwd: make ACL work in pipeline and eventdev modes": [2] > As was mentioned in the patch desctiption it was way too big, > controversial and incomplete. If the community is ok to introduce > pipeline model into the l3fwd, then it is propbably worth to be > a separate patch series. > > v1 -> v2: > - rename 'elmst/objst' to 'meta' (Morten) > - introduce new data-path APIs set: one with both meta{} and objs[], > second with just objs[] (Morten) > - split data-path APIs into burst/bulk flavours (same as rte_ring) > - added dump function for te_soring and improved dump() for rte_ring. > - dropped patch: > " ring: minimize reads of the counterpart cache-line" > - no performance gain observed > - actually it does change behavior of conventional rte_ring > enqueue/dequeue APIs - > it could return available/free less then actually exist in the ring. > As in some other libs we reliy on that information - it will > introduce problems. > > The main aim of these series is to extend ring library with > new API that allows user to create/use Staged-Ordered-Ring (SORING) > abstraction. In addition to that there are few other patches that serve > different purposes: > - first two patches are just code reordering to de-duplicate > and generalize existing rte_ring code. > - patch #3 extends rte_ring_dump() to correctly print head/tail metadata > for different sync modes. > - next two patches introduce SORING API into the ring library and > provide UT for it. > > SORING overview > =============== > Staged-Ordered-Ring (SORING) provides a SW abstraction for 'ordered' queues > with multiple processing 'stages'. It is based on conventional DPDK > rte_ring, re-uses many of its concepts, and even substantial part of > its code. > It can be viewed as an 'extension' of rte_ring functionality. > In particular, main SORING properties: > - circular ring buffer with fixed size objects > - producer, consumer plus multiple processing stages in between. > - allows to split objects processing into multiple stages. > - objects remain in the same ring while moving from one stage to the other, > initial order is preserved, no extra copying needed. > - preserves the ingress order of objects within the queue across multiple > stages > - each stage (and producer/consumer) can be served by single and/or > multiple threads. > > - number of stages, size and number of objects in the ring are > configurable at ring initialization time. > > Data-path API provides four main operations: > - enqueue/dequeue works in the same manner as for conventional rte_ring, > all rte_ring synchronization types are supported. > - acquire/release - for each stage there is an acquire (start) and > release (finish) operation. After some objects are 'acquired' - > given thread can safely assume that it has exclusive ownership of > these objects till it will invoke 'release' for them. > After 'release', objects can be 'acquired' by next stage and/or dequeued > by the consumer (in case of last stage). > > Expected use-case: applications that uses pipeline model > (probably with multiple stages) for packet processing, when preserving > incoming packet order is important. > > The concept of ‘ring with stages’ is similar to DPDK OPDL eventdev PMD [1], > but the internals are different. > In particular, SORING maintains internal array of 'states' for each element > in the ring that is shared by all threads/processes that access the ring. > That allows 'release' to avoid excessive waits on the tail value and helps > to improve performancei and scalability. > In terms of performance, with our measurements rte_soring and > conventional rte_ring provide nearly identical numbers. > As an example, on our SUT: Intel ICX CPU @ 2.00GHz, > l3fwd (--lookup=acl) in pipeline mode [2] both > rte_ring and rte_soring reach ~20Mpps for single I/O lcore and same > number of worker lcores. > > [1] https://www.dpdk.org/wp-content/uploads/sites/35/2018/06/DPDK-China2017-Ma-OPDL.pdf > [2] https://patchwork.dpdk.org/project/dpdk/patch/20240906131348.804-7-konstantin.v.ananyev@yandex.ru/ One future suggestion. What about having an example (l3fwd-soring?) so that performance can be compared. Assuming you get the other minor comments from Morten fixed. Series-Acked-by: Stephen Hemminger <stephen@networkplumber.org>
> > > The concept of ‘ring with stages’ is similar to DPDK OPDL eventdev PMD [1], > > but the internals are different. > > In particular, SORING maintains internal array of 'states' for each element > > in the ring that is shared by all threads/processes that access the ring. > > That allows 'release' to avoid excessive waits on the tail value and helps > > to improve performancei and scalability. > > In terms of performance, with our measurements rte_soring and > > conventional rte_ring provide nearly identical numbers. > > As an example, on our SUT: Intel ICX CPU @ 2.00GHz, > > l3fwd (--lookup=acl) in pipeline mode [2] both > > rte_ring and rte_soring reach ~20Mpps for single I/O lcore and same > > number of worker lcores. > > > > [1] https://www.dpdk.org/wp-content/uploads/sites/35/2018/06/DPDK-China2017-Ma-OPDL.pdf > > [2] https://patchwork.dpdk.org/project/dpdk/patch/20240906131348.804-7-konstantin.v.ananyev@yandex.ru/ > > One future suggestion. What about having an example (l3fwd-soring?) so > that performance can be compared. > On early stages (RFC) I submitted a patch which allows l3fwd (ACL-case) to work in sort of pipeline mode: https://patchwork.dpdk.org/project/dpdk/patch/20240906131348.804-7-konstantin.v.ananyev@yandex.ru/ So user can run it in one of the modes: run-to-completion/eventdev/rte_ring/rte_soring and measure performance differences. If there is a interest from the community, then yes we can try to make it a proper patch series for future releases.