From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id ADB3C45B1E;
	Sat, 12 Oct 2024 20:09:26 +0200 (CEST)
Received: from mails.dpdk.org (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 5A40640267;
	Sat, 12 Oct 2024 20:09:26 +0200 (CEST)
Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com
 [209.85.210.169])
 by mails.dpdk.org (Postfix) with ESMTP id C3F1C40265
 for <dev@dpdk.org>; Sat, 12 Oct 2024 20:09:24 +0200 (CEST)
Received: by mail-pf1-f169.google.com with SMTP id
 d2e1a72fcca58-71e580256c2so163846b3a.3
 for <dev@dpdk.org>; Sat, 12 Oct 2024 11:09:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1728756564;
 x=1729361364; darn=dpdk.org; 
 h=content-transfer-encoding:mime-version:references:in-reply-to
 :message-id:subject:cc:to:from:date:from:to:cc:subject:date
 :message-id:reply-to;
 bh=hP1AFL5H1IU/5lSl2Zusa86WbhkMivQoLCw/TsP6xqw=;
 b=UKv9yFZ+7/qgUuvOY1He9ZnaJsCzVUGfAUdHYqXp24vPu0pZfLWRFS93yKrmoYe3IT
 NJmNm3IS/BCV3Bo57GZwukeFzhqF8G1hYsa1Tz7T4h6UzLBk6i69BgR7hBUpq871EQLX
 eLxZENoSlM8C4pkoT8So4PQCrw94/sJSwVAlUIaL8LuhUI/+glXD5gWAtkW6dt9QsKB2
 GJr59kl0c8Np+WSpryHCtRJ1yV8R17RjKMUwxqh1v1/xEl7DzGLPMSdYijBuQMtFKcvG
 ynd8Dmk5zFl4JSpKJMInsCtgPPcM1/s+wR3smyhm6V0TGXJ38Nd2Kld9oreJqM0/j42c
 RDUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1728756564; x=1729361364;
 h=content-transfer-encoding:mime-version:references:in-reply-to
 :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc
 :subject:date:message-id:reply-to;
 bh=hP1AFL5H1IU/5lSl2Zusa86WbhkMivQoLCw/TsP6xqw=;
 b=gAj+XWUHyFV2kj7vPcdUbVDyx6ngV8RC/8Q6WSGoFHaHRBvNNxkWPd0xTLuUIFYtX/
 GdehT/0mPlL3bM1eJsLSdFPMsweI+13mKHQX6Cmk7VU1d9dB8MrdYIhS9WW9Zg92XZ8f
 b1oXZ3wQzWQG+E+WSKVW6zkLxJyj+Xy9b3m7fbe03Vi89rDpUgMpgEVXEXmqrsQx/kHq
 U7V+tPaEF+r3LeNu/pw/D7ygbymXubXCyF0XOz3WGWnVj2yQkmGTRHSLbKJpPlPKqk3L
 cWHVu81+3rbxjTzcrH8lx2OlRda9Dqa0DODA3axlgJeR/KIAAfNhm+3Yb6snZa+3L5l3
 ZKzw==
X-Gm-Message-State: AOJu0Yx5cLNjFqup8xrItfoOdG23OEn3ZM1AyKBs5jWwiayMc7nWh9Do
 PgJRDp7qy3Z7QqL+vyHt20W6xW/ysTwizCDz+h4kzVyNBSgqENk/Y9MzOJDjbk0=
X-Google-Smtp-Source: AGHT+IFH+t7ZC31/vW1V4sHypiwVVKqtEhKCFbXx1oif60c+9V1kPwlfDQPVKUESpXRZ1LeBCk6MXQ==
X-Received: by 2002:a05:6a20:c888:b0:1d0:3a32:c3f8 with SMTP id
 adf61e73a8af0-1d8bcfaa0ffmr9253459637.39.1728756563735; 
 Sat, 12 Oct 2024 11:09:23 -0700 (PDT)
Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226])
 by smtp.gmail.com with ESMTPSA id
 41be03b00d2f7-7ea448e4636sm4032199a12.18.2024.10.12.11.09.22
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sat, 12 Oct 2024 11:09:23 -0700 (PDT)
Date: Sat, 12 Oct 2024 11:09:21 -0700
From: Stephen Hemminger <stephen@networkplumber.org>
To: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
Cc: dev@dpdk.org, 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, Konstantin Ananyev
 <konstantin.ananyev@huawei.com>
Subject: Re: [PATCH v4 0/5] Stage-Ordered API and other extensions for ring
 library
Message-ID: <20241012110921.1e0bb575@hermes.local>
In-Reply-To: <20240917120946.1212-1-konstantin.v.ananyev@yandex.ru>
References: <20240916123733.994-1-konstantin.v.ananyev@yandex.ru>
 <20240917120946.1212-1-konstantin.v.ananyev@yandex.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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

On Tue, 17 Sep 2024 13:09:41 +0100
Konstantin Ananyev <konstantin.v.ananyev@yandex.ru> wrote:

> From: Konstantin Ananyev <konstantin.ananyev@huawei.com>
>=20
> v2 -> v3:
> - fix compilation/doxygen complains (attempt #2)
> - updated release notes
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> SORING overview
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Staged-Ordered-Ring (SORING) provides a SW abstraction for 'ordered' queu=
es
> 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 othe=
r,
>   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.
>=20
> - 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 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).
>=20
> Expected use-case: applications that uses pipeline model
> (probably with multiple stages) for packet processing, when preserving
> incoming packet order is important.
>=20
> The concept of =E2=80=98ring with stages=E2=80=99 is similar to DPDK OPDL=
 eventdev PMD [1],
> but the internals are different.
> In particular, SORING maintains internal array of 'states' for each eleme=
nt
> 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=3Dacl) in pipeline mode [2] both
> rte_ring and rte_soring reach ~20Mpps for single I/O lcore and same
> number of worker lcores.
>=20
> [1] https://www.dpdk.org/wp-content/uploads/sites/35/2018/06/DPDK-China20=
17-Ma-OPDL.pdf
> [2] https://patchwork.dpdk.org/project/dpdk/patch/20240906131348.804-7-ko=
nstantin.v.ananyev@yandex.ru/
>=20
> Eimear Morrissey (1):
>   ring: make dump function more verbose
>=20
> Konstantin Ananyev (4):
>   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
>=20
>  .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 +++++++++++++++++++++++++
>  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            | 134 +---
>  lib/ring/rte_ring_elem_pvt.h           | 181 ++++--
>  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                  | 543 ++++++++++++++++
>  lib/ring/soring.c                      | 548 ++++++++++++++++
>  lib/ring/soring.h                      | 124 ++++
>  lib/ring/version.map                   |  26 +
>  22 files changed, 3144 insertions(+), 396 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 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
>=20

Makes sense, fix the review comments please.
Also, to keep checkpatch spell checker from generating lots of false
positives; recommend updating build-dict.sh to elide soring from the genera=
ted dictionary.