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 58C6F457D5; Thu, 15 Aug 2024 14:41:05 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E1AB84027E; Thu, 15 Aug 2024 14:41:04 +0200 (CEST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by mails.dpdk.org (Postfix) with ESMTP id 5DE384025F for ; Thu, 15 Aug 2024 14:41:03 +0200 (CEST) Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Wl4R11ybkz6K97s; Thu, 15 Aug 2024 20:38:05 +0800 (CST) Received: from frapeml500005.china.huawei.com (unknown [7.182.85.13]) by mail.maildlp.com (Postfix) with ESMTPS id D10491400E7; Thu, 15 Aug 2024 20:41:01 +0800 (CST) Received: from frapeml500007.china.huawei.com (7.182.85.172) by frapeml500005.china.huawei.com (7.182.85.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Thu, 15 Aug 2024 14:41:01 +0200 Received: from frapeml500007.china.huawei.com ([7.182.85.172]) by frapeml500007.china.huawei.com ([7.182.85.172]) with mapi id 15.01.2507.039; Thu, 15 Aug 2024 14:41:01 +0200 From: Konstantin Ananyev To: =?iso-8859-1?Q?Morten_Br=F8rup?= , "Konstantin Ananyev" , "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" Subject: RE: [RFC 3/6] ring/soring: introduce Staged Ordered Ring Thread-Topic: [RFC 3/6] ring/soring: introduce Staged Ordered Ring Thread-Index: AQHa7vC1mkB/pilhbkGpjKPW9f7ZHLIoCHoAgAA2zGA= Date: Thu, 15 Aug 2024 12:41:01 +0000 Message-ID: <71059883ae384f798713361c3ffaa0f2@huawei.com> References: <20240815085339.1434-1-konstantin.v.ananyev@yandex.ru> <20240815085339.1434-4-konstantin.v.ananyev@yandex.ru> <98CBD80474FA8B44BF855DF32C47DC35E9F641@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F641@smartserver.smartshare.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.206.138.42] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 > > > > Staged-Ordered-Ring (SORING) provides a SW abstraction for 'ordered' qu= eues > > 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 ot= her, > > initial order is preserved, no extra copying needed. > > - preserves the ingress order of objects within the queue across multip= le > > 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. > > > > 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 th= at > > 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 deque= ued > > 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. I.E.: IPsec processing, etc. > > > > Signed-off-by: Konstantin Ananyev > > --- >=20 > The existing RING library is for a ring of objects. >=20 > It is very confusing that the new SORING library is for a ring of object = pairs (obj, objst). >=20 > The new SORING library should be for a ring of objects, like the existing= RING library. Please get rid of all the objst stuff. >=20 > This might also improve performance when not using the optional secondary= object. >=20 >=20 > With that in place, you can extend the SORING library with additional API= s for object pairs. >=20 > 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. I suppose what you suggest is to have 2 set of functions: one that takes bo= th objs[] and meta[] and second that takes just objs[]? If so, yes I can do that - in fact I was thinking about same thing. BTW, right now meta[] is an optional one anyway. Also will probably get rid of explicit 'behavior' and will have '_burst_' a= nd '_bulk_' versions instead, same as rte_ring.=20 >=20 > Furthermore, you should consider semi-zero-copy APIs for the "acquire"/"r= elease" functions: >=20 > The "acquire" function can use a concept similar to rte_pktmbuf_read(), w= here 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. You mean to introduce analog of rte_ring '_zc_' functions? Yes, I considered that, but decided to leave it for the future. First, because we do need a generic and simple function with copying things= anyway. Second I am not so convinced that this _zc_ will give much performance gain= , while it definitely makes API not that straightforward. =20 > And the "release" function does not need to copy the object vector back i= f the "acquire" function returned a zero-copy pointer. For "release" you don't need to *always* copy objs[] and meta[]. It is optional and is left for the user to decide based on the use-case. If he doesn't need to update objs[] or meta[] he can just pass a NULL ptr h= ere. =20