From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 08843A04BC; Thu, 8 Oct 2020 22:47:53 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B23711B774; Thu, 8 Oct 2020 22:47:50 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150088.outbound.protection.outlook.com [40.107.15.88]) by dpdk.org (Postfix) with ESMTP id 1BFDE1B70A for ; Thu, 8 Oct 2020 22:47:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hnsQEItQn2rShGUAQi0dRJW7lyEu1r0XZbvxxTkYWxc=; b=XWzVbNpQZWmFLA/LjEhUWL7Yfz2WViZUvETcskXcd2LWIyXDXvMcdw23EpOmzZKFMpnAqaJGy8VrIJyhuQJCXFFWEIxO375pyUnN0KymMmYSJVj2m/uI8EFBrUZl4N69XbT20li2J/i7+SGGaXvNQsMBXok5b+6FBg9T3hBigmA= Received: from DB6PR0301CA0096.eurprd03.prod.outlook.com (2603:10a6:6:30::43) by AM0PR08MB3506.eurprd08.prod.outlook.com (2603:10a6:208:db::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.22; Thu, 8 Oct 2020 20:47:46 +0000 Received: from DB5EUR03FT018.eop-EUR03.prod.protection.outlook.com (2603:10a6:6:30:cafe::61) by DB6PR0301CA0096.outlook.office365.com (2603:10a6:6:30::43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.21 via Frontend Transport; Thu, 8 Oct 2020 20:47:46 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dpdk.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dpdk.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT018.mail.protection.outlook.com (10.152.20.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.23 via Frontend Transport; Thu, 8 Oct 2020 20:47:46 +0000 Received: ("Tessian outbound 7161e0c2a082:v64"); Thu, 08 Oct 2020 20:47:46 +0000 X-CR-MTA-TID: 64aa7808 Received: from c90f80192406.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 5D4C04BC-334D-4C16-A6B8-1A79BF35ACBF.1; Thu, 08 Oct 2020 20:47:41 +0000 Received: from EUR04-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id c90f80192406.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 08 Oct 2020 20:47:41 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E1TaQnQryiHTArBrsiQ/b9lqxaJkMxFnZSlKJqnlph3RWWRLy3FvV6A62U49GcjPnW9qIlZm2tBWemlg/pWy+mwzjDtSvjOq1pd+U9zsgX4MtDtCglcxcSxFHBVuK9iOLyr2ObkqR/dD82aASnsJBxOnwWY6ny2JtRvzIw0yE7c/fiDX17biTK+XaVtoTigjt/cYbmumTgaEIf68u4eyHWTtLvt4RKpDiuJmhhGeN42TM6aLg7+4WuslKoW5ulbyZpKYrVVD+Op/RQR2U4GgbzQcUBINb43AhjjqwtDW962PVFY+sZp+kSz7pat+GtFr2pvf6oNJ1S0atCliETCOxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hnsQEItQn2rShGUAQi0dRJW7lyEu1r0XZbvxxTkYWxc=; b=obeyJ7OOcQL+2zBdXwBXd1yyScUzP4ebeBRxhs1JZ2hTUKAkKyWPfrNwZBvr1dyxgCRp4G8/iCeCHmr0TUQG+wAf2XTvewfcia0ev+LJCl+LDNw4uRgrvYYnd/NqAElopbwGsNHDOX2nLniIbLRVKWveXMxPSrul5sQZ1ojREZFGCyGE3nxwv9Gx0vTPPHkLBej6Kz1KthmG2D7DH1OheXDykeIAkGi/BbzamggTQVUn75BArVZi+KCiEXzTLnRRYM26421qgBXRz0LjQF8wnI3LhFKs6IPJzRXzVc9GnmUgmqHqJ+16xdhRFckkAlxMzpHQ5h6l26U1qy2ifRY9kg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hnsQEItQn2rShGUAQi0dRJW7lyEu1r0XZbvxxTkYWxc=; b=XWzVbNpQZWmFLA/LjEhUWL7Yfz2WViZUvETcskXcd2LWIyXDXvMcdw23EpOmzZKFMpnAqaJGy8VrIJyhuQJCXFFWEIxO375pyUnN0KymMmYSJVj2m/uI8EFBrUZl4N69XbT20li2J/i7+SGGaXvNQsMBXok5b+6FBg9T3hBigmA= Received: from DBAPR08MB5814.eurprd08.prod.outlook.com (2603:10a6:10:1b1::6) by DB6PR0802MB2549.eurprd08.prod.outlook.com (2603:10a6:4:a0::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.38; Thu, 8 Oct 2020 20:47:40 +0000 Received: from DBAPR08MB5814.eurprd08.prod.outlook.com ([fe80::7814:9c1:781f:475d]) by DBAPR08MB5814.eurprd08.prod.outlook.com ([fe80::7814:9c1:781f:475d%4]) with mapi id 15.20.3455.023; Thu, 8 Oct 2020 20:47:40 +0000 From: Honnappa Nagarahalli To: Olivier Matz CC: "dev@dpdk.org" , "konstantin.ananyev@intel.com" , "david.marchand@redhat.com" , nd , Honnappa Nagarahalli , nd Thread-Topic: [RFC v2 1/1] lib/ring: add scatter gather APIs Thread-Index: AQHWnIPUNOw1POr43kiYFPhsEItTcamOCuOggAAj7qA= Date: Thu, 8 Oct 2020 20:47:39 +0000 Message-ID: References: <20200224203931.21256-1-honnappa.nagarahalli@arm.com> <20201006132905.46205-1-honnappa.nagarahalli@arm.com> <20201006132905.46205-2-honnappa.nagarahalli@arm.com> <20201007082739.GL21395@platinum> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 3095736D4A36294BABA59CAC735B15D4.0 x-checkrecipientchecked: true Authentication-Results-Original: 6wind.com; dkim=none (message not signed) header.d=none;6wind.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [217.140.110.7] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: e0cb6d74-558e-4206-7274-08d86bcb6999 x-ms-traffictypediagnostic: DB6PR0802MB2549:|AM0PR08MB3506: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: WiZL3LwylpbEUv+8shLMQkVkG31ZivYZgpIvVqSjos7XI17ZylxO1XZ4gx/stvovdKXXERKvqZZ7Ez/mlvhvK3eNEp1NCXjLSf5kbIHDL1Nlo/rfsm8EiT8qOOcmIyAfMPbHjpEJOksO+o+MSBIbGzVpt8GyJdMve5Oa0qNNoKfbzbjWS2xMKZYefgI+ftIgxpARlxrRlEVtNIpQ4LD7gJXLlqGzUPjq3ElnpDrFe3UYkEAonh0uPawJ46dxOKQihSlRXW8K0Ko+5Z+KmdjzL4XzJzfsYaVidVf7J6Ox639o05XFLKWqDuPGry3xiduMYkMUTumDEg5+rStKnApxdA0qbrM6V0Ife0oKc5+aX3Fgv49KNIshk7MeIO3NZp1vU2UbYQ1CT5oxKup4X4J7ZQ== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBAPR08MB5814.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(39850400004)(366004)(136003)(396003)(55016002)(83380400001)(4326008)(33656002)(86362001)(66446008)(52536014)(76116006)(66556008)(8676002)(66476007)(66946007)(64756008)(186003)(71200400001)(26005)(54906003)(966005)(6506007)(8936002)(2940100002)(83080400001)(2906002)(6916009)(9686003)(316002)(7696005)(5660300002)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Hf059ywybZyrguEsmpei4JQ7ryDzbgkMPYrMbFXELQ11LkwSJCVh/X/P+ZPdoEv2sQpFzSXD7MxEKhWz7UqFMLcA1YqU7K+Yq5tvGL6ppe2EIDCAbCpNXK9fNF/+34WFd9Mi0xn6SVBBhQmOvpPCovZD7uzmkeHVt1yvOkQoSkT5uglJB6jmbNfUT7WVjet5LaqhnFuWXHHSbM8xeZAeLTyiSVS/bY4BqLDqh+phb/lp5Ixo82TIRrORyUUSC+MD9vB74937gDQVHkR2uskHvC/xCLd6e+egKUCn5FEjly6cJU+N/9c7Fj3bqwT5GnmvZGYmo4Kk3Y+CxWgudDPEaEAe0oH9NJu0ntVCE1x9OAM27hq7PNfjglyyv5L+RDriymu1iKOZh5+wrXF4f62HIR0ObSybjLiUWziI0Yjgn+SZeRfAkcuoKZinqE5mxZ5WA5/fQNW4R0glJte27dk0S2BDHpZ+2lPavadoy+saSBWqYCqC1sZvvP3XM+gPju781ZuTIli9Ua2IAJdFAaXFBmYDzJanVNXZmMRnP4XRMkgYQ2PddY0jw9NBc230ui0OMw/hfGT+xwbZXtd9mpbr1P0pu73u9JGsDgBqRkZiB6K4s5xmtwTNqZF7qlpE2uBanbyCOa4lSfNFRyzaUhwAXA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0802MB2549 Original-Authentication-Results: 6wind.com; dkim=none (message not signed) header.d=none;6wind.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT018.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: d26bc6bb-7171-463c-ea40-08d86bcb659b X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: sxXHeH4CfTNWF+450Eo1jf0IJy2/LiInMRuwHB9SAiqBiOBM5YSASOtbOBqu6KiCNCG+a0g25Zxpcq/jy4DMtNxFvZ2Yzqeg9y9GonxyhO1hhWnGH6Vnk3n0bWMBjhl2Hw17EyGuWWXmuvnTe2rM/fMTugTvka20ZCegiFKXLDOC6VIdK1vwMT/7Vr8F6ccawfkX3hyiFgP3zot0K2roGmGwzSRNo+Iuob5LsWsQzmvmRtuMrPGWWAZZopX2BlTVy4Zw37COsuJma60r9sseR/j201qpHnFKyqLe2Do0+xVe09pnPxLz+RU9heG2o9/f6Ty3czvBSSu54s13+N41IxYhwDVkWj27j3QNvDiU0KBF1+wKAQEkACJEdEWgZ6tt8SQgTN3DJfV8ZXV32IM6+B9tJLxJjfCbrqJoEb41rxXCx2TAMyw3GPFcFNVXW597+ikghn7ohKTTRJrci2+/DPVWBRjOHAO8nqPh62nCIzA= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(396003)(39850400004)(346002)(136003)(376002)(46966005)(83080400001)(8676002)(55016002)(83380400001)(6862004)(82740400003)(478600001)(47076004)(33656002)(54906003)(82310400003)(86362001)(4326008)(9686003)(316002)(356005)(8936002)(81166007)(966005)(52536014)(26005)(70206006)(186003)(6506007)(336012)(7696005)(70586007)(5660300002)(2940100002)(2906002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Oct 2020 20:47:46.7032 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e0cb6d74-558e-4206-7274-08d86bcb6999 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT018.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3506 Subject: Re: [dpdk-dev] [RFC v2 1/1] lib/ring: add scatter gather APIs X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" >=20 > > > > Hi Honnappa, > > > > From a quick walkthrough, I have some questions/comments, please see > > below. > Hi Olivier, appreciate your input. >=20 > > > > On Tue, Oct 06, 2020 at 08:29:05AM -0500, Honnappa Nagarahalli wrote: > > > Add scatter gather APIs to avoid intermediate memcpy. Use cases that > > > involve copying large amount of data to/from the ring can benefit > > > from these APIs. > > > > > > Signed-off-by: Honnappa Nagarahalli > > > --- > > > lib/librte_ring/meson.build | 3 +- > > > lib/librte_ring/rte_ring_elem.h | 1 + > > > lib/librte_ring/rte_ring_peek_sg.h | 552 > > > +++++++++++++++++++++++++++++ > > > 3 files changed, 555 insertions(+), 1 deletion(-) create mode > > > 100644 lib/librte_ring/rte_ring_peek_sg.h > > > > > > diff --git a/lib/librte_ring/meson.build > > > b/lib/librte_ring/meson.build index 31c0b4649..377694713 100644 > > > --- a/lib/librte_ring/meson.build > > > +++ b/lib/librte_ring/meson.build > > > @@ -12,4 +12,5 @@ headers =3D files('rte_ring.h', > > > 'rte_ring_peek.h', > > > 'rte_ring_peek_c11_mem.h', > > > 'rte_ring_rts.h', > > > - 'rte_ring_rts_c11_mem.h') > > > + 'rte_ring_rts_c11_mem.h', > > > + 'rte_ring_peek_sg.h') > > > diff --git a/lib/librte_ring/rte_ring_elem.h > > > b/lib/librte_ring/rte_ring_elem.h index 938b398fc..7d3933f15 100644 > > > --- a/lib/librte_ring/rte_ring_elem.h > > > +++ b/lib/librte_ring/rte_ring_elem.h > > > @@ -1079,6 +1079,7 @@ rte_ring_dequeue_burst_elem(struct rte_ring > > > *r, void *obj_table, > > > > > > #ifdef ALLOW_EXPERIMENTAL_API > > > #include > > > +#include > > > #endif > > > > > > #include > > > diff --git a/lib/librte_ring/rte_ring_peek_sg.h > > > b/lib/librte_ring/rte_ring_peek_sg.h > > > new file mode 100644 > > > index 000000000..97d5764a6 > > > --- /dev/null > > > +++ b/lib/librte_ring/rte_ring_peek_sg.h > > > @@ -0,0 +1,552 @@ > > > +/* SPDX-License-Identifier: BSD-3-Clause > > > + * > > > + * Copyright (c) 2020 Arm > > > + * Copyright (c) 2007-2009 Kip Macy kmacy@freebsd.org > > > + * All rights reserved. > > > + * Derived from FreeBSD's bufring.h > > > + * Used as BSD-3 Licensed with permission from Kip Macy. > > > + */ > > > + > > > +#ifndef _RTE_RING_PEEK_SG_H_ > > > +#define _RTE_RING_PEEK_SG_H_ > > > + > > > +/** > > > + * @file > > > + * @b EXPERIMENTAL: this API may change without prior notice > > > + * It is not recommended to include this file directly. > > > + * Please include instead. > > > + * > > > + * Ring Peek Scatter Gather APIs > > > > I am not fully convinced by the API name. To me, "scatter/gather" is > > associated to iovecs, like for instance in [1]. The wikipedia > > definition [2] may be closer though. > > > > [1] > > > https://www.gnu.org/software/libc/manual/html_node/Scatter_002dGathe > > r.html > > [2] https://en.wikipedia.org/wiki/Gather-scatter_(vector_addressing) > The way I understand scatter-gather is, the data to be sent to something = (like > a device) is coming from multiple sources. It would require copying to pu= t the > data together to be contiguous. If the device supports scatter-gather, su= ch > copying is not required. The device can collect data from multiple locati= ons > and make it contiguous. >=20 > In the case I was looking at, one part of the data was coming from the us= er of > the API and another was generated by the API itself. If these two pieces = of > information have to be enqueued as a single object on the ring, I had to > create an intermediate copy. But by exposing the ring memory to the user, > the intermediate copy is avoided. Hence I called it scatter-gather. >=20 > > > > What about "zero-copy"? > I think no-copy (nc for short) or user-copy (uc for short) would convey t= he > meaning better. These would indicate that the rte_ring APIs are not copyi= ng > the objects and it is left to the user to do the actual copy. >=20 > > > > Also, the "peek" term looks also a bit confusing to me, but it existed > > before your patch. I understand it for dequeue, but not for enqueue. > I kept 'peek' there because the API still offers the 'peek' API capabilit= ies. I am > also not sure on what 'peek' means for enqueue API. The enqueue 'peek' > API was provided to be symmetric with dequeue peek API. >=20 > > > > Or, what about replacing the existing experimental peek API by this one= ? > > They look quite similar to me. > I agree, scatter gather APIs provide the peek capability and the no-copy > benefits. > Konstantin, any opinions here? >=20 > > > > > + * Introduction of rte_ring with scatter gather serialized > > > + producer/consumer > > > + * (HTS sync mode) makes it possible to split public > > > + enqueue/dequeue API > > > + * into 3 phases: > > > + * - enqueue/dequeue start > > > + * - copy data to/from the ring > > > + * - enqueue/dequeue finish > > > + * Along with the advantages of the peek APIs, these APIs provide > > > + the ability > > > + * to avoid copying of the data to temporary area. > > > + * > > > + * Note that right now this new API is available only for two sync m= odes: > > > + * 1) Single Producer/Single Consumer (RTE_RING_SYNC_ST) > > > + * 2) Serialized Producer/Serialized Consumer > (RTE_RING_SYNC_MT_HTS). > > > + * It is a user responsibility to create/init ring with appropriate > > > + sync > > > + * modes selected. > > > + * > > > + * Example usage: > > > + * // read 1 elem from the ring: > > > > Comment should be "prepare enqueuing 32 objects" > > > > > + * n =3D rte_ring_enqueue_sg_bulk_start(ring, 32, &sgd, NULL); > > > + * if (n !=3D 0) { > > > + * //Copy objects in the ring > > > + * memcpy (sgd->ptr1, obj, sgd->n1 * sizeof(uintptr_t)); > > > + * if (n !=3D sgd->n1) > > > + * //Second memcpy because of wrapround > > > + * n2 =3D n - sgd->n1; > > > + * memcpy (sgd->ptr2, obj[n2], n2 * sizeof(uintptr_t)); > > > > Missing { } > > > > > + * rte_ring_dequeue_sg_finish(ring, n); > > > > Should be enqueue > > > Thanks, will correct them. >=20 > > > + * } > > > + * > > > + * Note that between _start_ and _finish_ none other thread can > > > + proceed > > > + * with enqueue(/dequeue) operation till _finish_ completes. > > > + */ > > > + > > > +#ifdef __cplusplus > > > +extern "C" { > > > +#endif > > > + > > > +#include > > > + > > > +/* Rock that needs to be passed between reserve and commit APIs */ > > > +struct rte_ring_sg_data { > > > + /* Pointer to the first space in the ring */ > > > + void **ptr1; > > > + /* Pointer to the second space in the ring if there is wrap-around = */ > > > + void **ptr2; > > > + /* Number of elements in the first pointer. If this is equal to > > > + * the number of elements requested, then ptr2 is NULL. > > > + * Otherwise, subtracting n1 from number of elements requested > > > + * will give the number of elements available at ptr2. > > > + */ > > > + unsigned int n1; > > > +}; > > > > Would it be possible to simply return the offset instead of this struct= ure? > > The wrap could be managed by a __rte_ring_enqueue_elems() function. > Trying to use __rte_ring_enqueue_elems() will force temporary copy. See > below. >=20 > > > > I mean something like this: > > > > uint32_t start; > > n =3D rte_ring_enqueue_sg_bulk_start(ring, 32, &start, NULL); > > if (n !=3D 0) { > > /* Copy objects in the ring. */ > > __rte_ring_enqueue_elems(ring, start, obj, sizeof(uintptr_t), > n); > For ex: 'obj' here is temporary copy. The example I provided in the comment at the top of the file is not good. I= will replace the 'memcpy' with calling another API that copies the data to= the ring directly. That should show the clear benefit. >=20 > > rte_ring_enqueue_sg_finish(ring, n); > > } > > > > It would require to slightly change __rte_ring_enqueue_elems() to > > support to be called with prod_head >=3D size, and wrap in that case. > > > The alternate solution I can think of requires 3 things 1) the base addre= ss of > the ring 2) Index to where to copy 3) the mask. With these 3 things one c= ould > write the code like below: > for (i =3D 0; i < n; i++) { > ring_addr[(index + i) & mask] =3D obj[i]; // ANDing with mask will take > care of wrap-around. > } >=20 > However, I think this does not allow for passing the address in the ring = to > another function/API to copy the data (It is possible, but the user has t= o > calculate the actual address, worry about the wrap-around, second pointer > etc). >=20 > The current approach hides some details and provides flexibility to the > application to use the pointer the way it wants. >=20 > > > > Regards, > > Olivier