From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id C8DD44557F; Fri, 6 Sep 2024 15:14:14 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A96274025D; Fri, 6 Sep 2024 15:14:14 +0200 (CEST) Received: from forward501b.mail.yandex.net (forward501b.mail.yandex.net [178.154.239.145]) by mails.dpdk.org (Postfix) with ESMTP id 2C4CB400D5 for ; Fri, 6 Sep 2024 15:14:13 +0200 (CEST) Received: from mail-nwsmtp-smtp-production-main-39.sas.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-39.sas.yp-c.yandex.net [IPv6:2a02:6b8:c08:f220:0:640:b85:0]) by forward501b.mail.yandex.net (Yandex) with ESMTPS id 9CFC161DFA; Fri, 6 Sep 2024 16:14:12 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-39.sas.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id 3EetriBYuiE0-bQMlSnCa; Fri, 06 Sep 2024 16:14:11 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1725628451; bh=WIis8yEoP/YpC6RZuP1w83yvw5fNVmPuAKAXcCiZrTI=; h=Cc:Message-Id:References:Date:In-Reply-To:Subject:To:From; b=vZXb/wOA/WG/+nVV26JOj3VLf+9A8WDni7uVIc1vzdC04Y8pW9aXCpyt1uIgUssV+ f6d7Ic30cglnN0RHN8rvlV9fSrXWQ1jEvxpso6DYPLGji9g2Qiziknaj6DXMLtDSgh TVvhjz6lIfxBwaVkTktigX6cJmoPaV/+VyuzpcMc= Authentication-Results: mail-nwsmtp-smtp-production-main-39.sas.yp-c.yandex.net; dkim=pass header.i=@yandex.ru From: Konstantin Ananyev 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 Subject: [RFCv2 0/6] Stage-Ordered API and other extensions for ring library Date: Fri, 6 Sep 2024 14:13:42 +0100 Message-Id: <20240906131348.804-1-konstantin.v.ananyev@yandex.ru> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20240815085339.1434-1-konstantin.v.ananyev@yandex.ru> References: <20240815085339.1434-1-konstantin.v.ananyev@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org From: Konstantin Ananyev v1 -> v2: - dropped - 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 from v1: " 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. - patch #6 extends l3fwd sample app to work in pipeline (worker-pool) mode. Right now it is done for demonstration and performance comparison purposes, as 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. Seeking community help/feedback (apart from usual patch review activity): ========================================================================= - While we tested these changes quite extensively, our platform coverage is limitedi to x86. So would appreciate the feedback how it behaves on other architectures DPDK supports (ARM, PPC, etc.). - 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 Eimear Morrissey (1): ring: make dump function more verbose Konstantin Ananyev (5): 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 .mailmap | 1 + app/test/meson.build | 3 + app/test/test_ring_stress_impl.h | 1 + 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 | 827 +++++++++++++++++++++++++++++ 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 | 130 +++++ examples/l3fwd/main.c | 75 ++- examples/l3fwd/meson.build | 1 + lib/ring/meson.build | 4 +- lib/ring/rte_ring.c | 87 ++- lib/ring/rte_ring.h | 15 + lib/ring/rte_ring_c11_pvt.h | 134 +---- lib/ring/rte_ring_elem_pvt.h | 183 +++++-- lib/ring/rte_ring_generic_pvt.h | 121 +---- lib/ring/rte_ring_hts_elem_pvt.h | 85 +-- lib/ring/rte_ring_rts_elem_pvt.h | 85 +-- lib/ring/rte_soring.c | 182 +++++++ lib/ring/rte_soring.h | 547 +++++++++++++++++++ lib/ring/soring.c | 548 +++++++++++++++++++ lib/ring/soring.h | 124 +++++ lib/ring/version.map | 26 + 31 files changed, 4095 insertions(+), 425 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