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 0556F457D4; Thu, 15 Aug 2024 13:12:04 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E54984027E; Thu, 15 Aug 2024 13:12:03 +0200 (CEST) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 7A3274025F for ; Thu, 15 Aug 2024 13:12:02 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id 31D6A20EE7; Thu, 15 Aug 2024 13:12:02 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [RFC 3/6] ring/soring: introduce Staged Ordered Ring Date: Thu, 15 Aug 2024 13:11:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9F641@smartserver.smartshare.dk> In-Reply-To: <20240815085339.1434-4-konstantin.v.ananyev@yandex.ru> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RFC 3/6] ring/soring: introduce Staged Ordered Ring Thread-Index: Adru8LJFXoq39MQ5Tsu00kixHju4hAADfLtA References: <20240815085339.1434-1-konstantin.v.ananyev@yandex.ru> <20240815085339.1434-4-konstantin.v.ananyev@yandex.ru> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Konstantin Ananyev" , Cc: , , , , , , "Konstantin Ananyev" 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 >=20 > 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 the middle. > - 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, i.e.: > at the same stage multiple threads can process objects from the ring = in > any order, but for the next stage objects will always appear in the > original order. > - 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. >=20 > 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 possession of these objects till 'release' for them = is > invoked. > Note that right now user has to release exactly the same number of > objects that was acquired before. > After 'release', objects can be 'acquired' by next stage and/or = dequeued > by the consumer (in case of last stage). >=20 > Expected use-case: applications that uses pipeline model > (probably with multiple stages) for packet processing, when preserving > incoming packet order is important. I.E.: IPsec processing, etc. >=20 > Signed-off-by: Konstantin Ananyev > --- The existing RING library is for a ring of objects. It is very confusing that the new SORING library is for a ring of object = pairs (obj, objst). The new SORING library should be for a ring of objects, like the = existing RING library. Please get rid of all the objst stuff. This might also improve performance when not using the optional = secondary object. With that in place, you can extend the SORING library with additional = APIs for object pairs. I suggest calling the secondary object "metadata" instead of "status" or = "state" or "ret-value". I agree that data passed as {obj[num], meta[num]} is more efficient than = {obj, meta}[num] in some use cases, which is why your API uses two = vector pointers instead of one. Furthermore, you should consider semi-zero-copy APIs for the = "acquire"/"release" functions: The "acquire" function can use a concept similar to rte_pktmbuf_read(), = where a vector is provided for copying (if the ring wraps), and the = return value either points directly to the objects in the ring = (zero-copy), or to the vector where the objects were copied to. And the "release" function does not need to copy the object vector back = if the "acquire" function returned a zero-copy pointer.