From: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
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,
Konstantin Ananyev <konstantin.ananyev@huawei.com>
Subject: [RFC 0/6] Stage-Ordered API and other extensions for ring library
Date: Thu, 15 Aug 2024 09:53:33 +0100 [thread overview]
Message-ID: <20240815085339.1434-1-konstantin.v.ananyev@yandex.ru> (raw)
From: Konstantin Ananyev <konstantin.ananyev@huawei.com>
Konstantin Ananyev (6):
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
examples/l3fwd: make ACL work in pipeline and eventdev modes
ring: minimize reads of the counterpart cache-line
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.
- next two patches introduce SORING API into the ring library and
provide UT for it.
- patch #5 extends l3fwd sample app to work in pipeline (worker-pool) mode.
Right now it is done for demonstration and performance comparison pruposes:
it makes possible to run l3fwd in different modes:
run-to-completion, eventdev, pipeline
and perform sort-of 'apple-to-apple' performance comparisons.
I am aware that in general community consensus on l3fwd is to keep its
functionality simple and limited. From other side we already do have
eventdev mode for it, so why pipeline should be prohibited?
Though if l3fwd is not an option, then we need to select some other
existing sample app to integrate with. Probably ipsec-secgw would be the
second best choice from my perspective, though it would require much more
effort.
Have to say that current l3fwd patch is way too big and unfinished,
so if we'll decide to go forward with it, it has to be split and reworked.
- patch #6 - attempt to optimize (by caching counter-part tail value)
enqueue/dequeue operations for vanilla rte_ring. Logically tt is not linked
with patches 3-5 and probably should be in a separate series.
I put it here for now just to minimize 'Depends-on' hassle, so everyone
can build/try everything in one go.
Seeking community help/feedback (apart from usual patch review activity):
=========================================================================
- While we tested these changes quite extensively, our platform coverage
is limited to x86 right now.
So would appreciate the feedback how it behaves on other architectures
DPDK supports (ARM, PPC, etc.).
Specially for patch #6: so far we didn't observe noticeable performance
improvement with it on x86_64,
So if there would be no real gain on other platforms (or scenarios) -
I am ok to drop that patch.
- Adding new (pipeline) mode for l3fwd sample app.
Is it worth it? If not, what other sample app should be used to
demonstrate new functionality we worked on? ipsec-secgw? Something else?
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 (see patch #5 for details) 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
app/test/meson.build | 3 +
app/test/test_soring.c | 452 ++++++++++++++++
app/test/test_soring_mt_stress.c | 45 ++
app/test/test_soring_stress.c | 48 ++
app/test/test_soring_stress.h | 35 ++
app/test/test_soring_stress_impl.h | 832 +++++++++++++++++++++++++++++
drivers/net/mlx5/mlx5_hws_cnt.h | 5 +-
drivers/net/ring/rte_eth_ring.c | 2 +-
examples/l3fwd/l3fwd.h | 55 ++
examples/l3fwd/l3fwd_acl.c | 125 ++++-
examples/l3fwd/l3fwd_acl_event.h | 258 +++++++++
examples/l3fwd/l3fwd_event.c | 14 +
examples/l3fwd/l3fwd_event.h | 1 +
examples/l3fwd/l3fwd_sse.h | 49 +-
examples/l3fwd/l3fwd_wqp.c | 274 ++++++++++
examples/l3fwd/l3fwd_wqp.h | 132 +++++
examples/l3fwd/main.c | 75 ++-
examples/l3fwd/meson.build | 1 +
lib/ring/meson.build | 4 +-
lib/ring/rte_ring.c | 6 +-
lib/ring/rte_ring_c11_pvt.h | 134 +----
lib/ring/rte_ring_core.h | 12 +-
lib/ring/rte_ring_elem_pvt.h | 183 +++++--
lib/ring/rte_ring_generic_pvt.h | 153 ++----
lib/ring/rte_ring_hts_elem_pvt.h | 85 +--
lib/ring/rte_ring_peek_elem_pvt.h | 4 +-
lib/ring/rte_ring_rts_elem_pvt.h | 85 +--
lib/ring/rte_soring.c | 144 +++++
lib/ring/rte_soring.h | 270 ++++++++++
lib/ring/soring.c | 446 ++++++++++++++++
lib/ring/soring.h | 124 +++++
lib/ring/version.map | 13 +
32 files changed, 3632 insertions(+), 437 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 examples/l3fwd/l3fwd_acl_event.h
create mode 100644 examples/l3fwd/l3fwd_wqp.c
create mode 100644 examples/l3fwd/l3fwd_wqp.h
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
next reply other threads:[~2024-08-15 8:53 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-15 8:53 Konstantin Ananyev [this message]
2024-08-15 8:53 ` [RFC 1/6] ring: common functions for 'move head' ops Konstantin Ananyev
2024-08-15 8:53 ` [RFC 2/6] ring: make copying functions generic Konstantin Ananyev
2024-08-15 8:53 ` [RFC 3/6] ring/soring: introduce Staged Ordered Ring Konstantin Ananyev
2024-08-15 11:11 ` Morten Brørup
2024-08-15 12:41 ` Konstantin Ananyev
2024-08-15 13:22 ` Morten Brørup
2024-08-26 19:04 ` Mattias Rönnblom
2024-09-03 13:55 ` Konstantin Ananyev
2024-08-15 8:53 ` [RFC 4/6] app/test: add unit tests for soring API Konstantin Ananyev
2024-08-15 8:53 ` [RFC 5/6] examples/l3fwd: make ACL work in pipeline and eventdev modes Konstantin Ananyev
2024-08-15 8:53 ` [RFC 6/6] ring: minimize reads of the counterpart cache-line Konstantin Ananyev
2024-09-06 13:13 ` [RFCv2 0/6] Stage-Ordered API and other extensions for ring library Konstantin Ananyev
2024-09-06 13:13 ` [RFCv2 1/6] ring: common functions for 'move head' ops Konstantin Ananyev
2024-09-06 13:13 ` [RFCv2 2/6] ring: make copying functions generic Konstantin Ananyev
2024-09-06 13:13 ` [RFCv2 3/6] ring: make dump function more verbose Konstantin Ananyev
2024-09-06 13:13 ` [RFCv2 4/6] ring/soring: introduce Staged Ordered Ring Konstantin Ananyev
2024-09-06 13:13 ` [RFCv2 5/6] app/test: add unit tests for soring API Konstantin Ananyev
2024-09-06 13:13 ` [RFCv2 6/6] examples/l3fwd: make ACL work in pipeline and eventdev modes Konstantin Ananyev
2024-09-16 12:37 ` [PATCH v3 0/5] Stage-Ordered API and other extensions for ring library Konstantin Ananyev
2024-09-16 12:37 ` [PATCH v3 1/5] ring: common functions for 'move head' ops Konstantin Ananyev
2024-09-16 12:37 ` [PATCH v3 2/5] ring: make copying functions generic Konstantin Ananyev
2024-09-16 12:37 ` [PATCH v3 3/5] ring: make dump function more verbose Konstantin Ananyev
2024-09-16 12:37 ` [PATCH v3 4/5] ring/soring: introduce Staged Ordered Ring Konstantin Ananyev
2024-09-16 12:37 ` [PATCH v3 5/5] app/test: add unit tests for soring API Konstantin Ananyev
2024-09-17 12:09 ` [PATCH v4 0/5] Stage-Ordered API and other extensions for ring library Konstantin Ananyev
2024-09-17 12:09 ` [PATCH v4 1/5] ring: common functions for 'move head' ops Konstantin Ananyev
2024-09-17 12:09 ` [PATCH v4 2/5] ring: make copying functions generic Konstantin Ananyev
2024-09-17 12:09 ` [PATCH v4 3/5] ring: make dump function more verbose Konstantin Ananyev
2024-09-17 12:09 ` [PATCH v4 4/5] ring/soring: introduce Staged Ordered Ring Konstantin Ananyev
2024-09-17 12:09 ` [PATCH v4 5/5] app/test: add unit tests for soring API Konstantin Ananyev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240815085339.1434-1-konstantin.v.ananyev@yandex.ru \
--to=konstantin.v.ananyev@yandex.ru \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=drc@linux.vnet.ibm.com \
--cc=hemant.agrawal@nxp.com \
--cc=honnappa.nagarahalli@arm.com \
--cc=jerinj@marvell.com \
--cc=konstantin.ananyev@huawei.com \
--cc=mb@smartsharesystems.com \
--cc=ruifeng.wang@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).