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 B6305A04BC; Thu, 8 Oct 2020 22:44:28 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E1CCE1B67B; Thu, 8 Oct 2020 22:44:26 +0200 (CEST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70059.outbound.protection.outlook.com [40.107.7.59]) by dpdk.org (Postfix) with ESMTP id 140AD1B677 for ; Thu, 8 Oct 2020 22:44:23 +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=wolqoNDF4jCwCx5A0tPeEOCQGTzmdG1NHNOzZmAsSZM=; b=tojRTzY4JRrqUR719yfVuGt5oaCYsxuhwuVXq38F9mfutJysM5BiBdGGcKmdq/bYBwrv8gS1Ke7Zup5+NLZk2Gry9F8WDHG3xuDG0/p5Q8R+hmZ5NErB22GDk3ODiIg7dP5uAumnrsnfZ3na6PrYvHwNNNfcPo7Z12+bdN2Me4w= Received: from MR2P264CA0118.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:33::34) by HE1PR0801MB2121.eurprd08.prod.outlook.com (2603:10a6:3:80::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.37; Thu, 8 Oct 2020 20:44:21 +0000 Received: from VE1EUR03FT022.eop-EUR03.prod.protection.outlook.com (2603:10a6:500:33:cafe::d9) by MR2P264CA0118.outlook.office365.com (2603:10a6:500:33::34) 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:44:21 +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 VE1EUR03FT022.mail.protection.outlook.com (10.152.18.64) 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:44:20 +0000 Received: ("Tessian outbound 7fc8f57bdedc:v64"); Thu, 08 Oct 2020 20:44:19 +0000 X-CR-MTA-TID: 64aa7808 Received: from 075e38900008.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 629EB055-3FF8-4154-AF41-C92FC5C31362.1; Thu, 08 Oct 2020 20:44:14 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 075e38900008.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 08 Oct 2020 20:44:14 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UaZf7c4hCaZczsX718GjMe2jofs6IH077sulUXhwC4yc80gc1csoce2U4GPXSa/ViRcTqju7hMMvCrnMcM6Pqm/Un8tbgL0dfXmXEceBNRHD5yVyzHKK+Tjtc2pjLjKnd1Qu6zvKArQazEKaQYzkUV2uvieooNvvBQktjqgiyarMV8wM4a0zI1w22i0E58827erhD+yu19RL7o99D7qvuzRhdEIuDKyRWhF5WyGBSR8YbjSRT9aMlLBYAuSHXysTTG8DnVDArOJFR/2VFaxua8xBRf9aUSblzY9NgOnuMzOm42j0xj57t18MsXHkKDDi+xrcMPF8mx262nnh5F507Q== 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=wolqoNDF4jCwCx5A0tPeEOCQGTzmdG1NHNOzZmAsSZM=; b=LQOyMMCbkmJKEcjRppx09ER+yfWzPgbieHGd2hq93Vp/8RUveEwmT39NWiJOOdYQBWpmLhHx5qqDJv/1Ztg84VgGLduMCxyezBV8tisR9Ty8E5aCvRvdpw3AVCEsTNg8/ZzLbib2m+4V5U5NpvH/ClvC1uGPDaUAighqsMfTUUBV/UzHnweopSEv+H4Bf1gW46qhcfjc0aUB9n9tXKlkmXxwc7Z9/pb/DPcrnAA8g+ggprbYQZe8Sq0X4AMcV+N/+ZxUT0JZrqxyWiSUjyhd7K41drUzWCMfJhcqCg8PnktqLeW6rNfssEN7tEVKMeF3dd3NrPzDCP3v0gthhNWS8A== 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=wolqoNDF4jCwCx5A0tPeEOCQGTzmdG1NHNOzZmAsSZM=; b=tojRTzY4JRrqUR719yfVuGt5oaCYsxuhwuVXq38F9mfutJysM5BiBdGGcKmdq/bYBwrv8gS1Ke7Zup5+NLZk2Gry9F8WDHG3xuDG0/p5Q8R+hmZ5NErB22GDk3ODiIg7dP5uAumnrsnfZ3na6PrYvHwNNNfcPo7Z12+bdN2Me4w= Received: from DBAPR08MB5814.eurprd08.prod.outlook.com (2603:10a6:10:1b1::6) by DBBPR08MB4443.eurprd08.prod.outlook.com (2603:10a6:10:c8::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.23; Thu, 8 Oct 2020 20:44:13 +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:44:13 +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: AQHWnIPUNOw1POr43kiYFPhsEItTcamOCuOg Date: Thu, 8 Oct 2020 20:44:13 +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: <20201007082739.GL21395@platinum> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 9C7F950135768543B573C6DB38B0AE25.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: 15fe62ad-d1a4-42b5-e5ea-08d86bcaeecf x-ms-traffictypediagnostic: DBBPR08MB4443:|HE1PR0801MB2121: 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: Y/dEhDw4PFSnEvk704Kxd4FiubdgU7GVXXQhzQQdCjY6IzcSK8e5cWskksarbsNukRhseQ/MNDd0nXmqrrhb+3uBijXK2KMnxucMp+Ona6cM9E0FgNgRf8/hL103v2dvdOpfdpxB1LD/Y29t/i7MbuBzr/SNntKuAAgaHB4jPNhwbqS2EipXL9CMbubbDNMw1KACe+XV7vBZjbdMCqUtQM0Kt5ezBc+YdH/hweQuQL7YRK5r5rBnlH7F40tn0/3q8ry0S24jPObQGeFlRKZFckO/aB/Wd6dxP2vp2yxJLgeT+rSw0w9U7+semxo1L9rMatRn5prK4Jy2HPt7VEDDs3hFEUWwsZ35TsmlVzoyZ9PK+fOQb9uvAakZ6XhABwqXafXvDwRXub7lqDSlsNt0Qw== 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)(366004)(376002)(396003)(136003)(346002)(39850400004)(6506007)(316002)(4326008)(76116006)(478600001)(54906003)(6916009)(33656002)(71200400001)(64756008)(83080400001)(7696005)(66446008)(83380400001)(8676002)(2906002)(66556008)(966005)(66476007)(66946007)(26005)(186003)(5660300002)(86362001)(55016002)(9686003)(52536014)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: B3ZNMiaINtw3bKjLA68mg3EXuQkjfEhwVB4gL28qd3Y+rH8i8LXCOeVUpfBjIJW+PFDPhKiuR75y7fC7J8mS9NNLsjOvPf7ZHB3IgCRLqkRbFIrZ5SZJwJnkdDuD/kGlHENGr53rP+cGtCMj/vePpm25zYL/1l5q0jp9q9sCH4m0obhdfqY7XjTQbxHQOBx/WP9jUXBpGlGScJxHtdTOQrHlUuknaS3z3Xmgv7T4QRVX3dp/Nhyj+gewuHK/ueHGal7VDFr9IsMl4GDN3C35rIYa6fKibIN7uuBkFhhhElC98LACC2/zE0nV6dDCY/L7CgFQNBJ6EMNWhCS4dtJD8hZgs1lJUhoLwJxPgCV3UN3kRC3cozBET1Y0kJ6v4ix+xkB4gycaeVhpGka8gNR+KftnMbVJm0PXAihCknm97PmlrdkntnqrkSs2D7t2hOS1/ub/GVxKdwBj+vCLJqzu2BGBbG7C5E724qKe6R16wg9+FsSnE0/WwAmLFGHPeGEY8fmlU3+49C9MRVWIMUa7YqwrvVlWqUpFoaWUZgMziFfuAnZET88A1LiIxJ98sYvsCHoB7Vd5mmjRoYxniP9ueiLLZQIgFiR8Ci+clG1yaCIh50i0BCM/QOxCsd9pIVDeVfz2Cfn2e0ag12cMhHw3PA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB4443 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: VE1EUR03FT022.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: f1355844-e543-466d-126d-08d86bcaea70 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: OFDsRaYmQ7op2gB9CDgAiCuob9pMrFu5seo0/zwI5P7cdPFskTcX5Vk9l5/+Q7dDxFXzfcl8Psl3sYe6C36xsLSDVbu+O3+xLyS5DMIG8hCuJ4JbNa8FxpmNrDkHPiWO/fmT+WG8LumpMnvmBcgRDmok/eIOIVeeiOeqEBkqiw9TMukktdKQcIo7SlxMAFr+hjpWbUpqUp/CqNRV/KmC1q7C2J59X8PhAcYgNgpTlvoyG4oYgMR7NWAFoEdGsqY0iKQ0p+75AVkba1/Janjh7UDrC/oaD4MQ+VwM/LwEGZ5mq+sSOsQNY57/mjM+UlJsRPwDElqYrm0/1HprA4rErKcmz8ZLNYgvTHLHSXLAvtubf0l/DBEiAyDXKvD4pQvC6rdmvTmfh1PdJyuSWZSRoVVmRYBG9N5wGadhAHEk54I1UlTTluM/0MNxATbCipYgWlw3Wn1KOBUU+I43mub7Ysh/y3gd2wta9d9SJAHrZD4= 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)(136003)(346002)(396003)(376002)(39850400004)(46966005)(26005)(83380400001)(82740400003)(6506007)(8676002)(966005)(2906002)(5660300002)(55016002)(186003)(356005)(47076004)(81166007)(478600001)(83080400001)(4326008)(6862004)(70206006)(7696005)(54906003)(86362001)(70586007)(82310400003)(8936002)(52536014)(33656002)(316002)(336012)(9686003); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Oct 2020 20:44:20.5973 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 15fe62ad-d1a4-42b5-e5ea-08d86bcaeecf 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: VE1EUR03FT022.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0801MB2121 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, >=20 > 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 >=20 > 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. >=20 > [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 (l= ike a device) is coming from multiple sources. It would require copying to = put the data together to be contiguous. If the device supports scatter-gath= er, such copying is not required. The device can collect data from multiple= locations and make it contiguous. In the case I was looking at, one part of the data was coming from the user= of the API and another was generated by the API itself. If these two piece= s 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 the= meaning better. These would indicate that the rte_ring APIs are not copyin= g 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 be= fore > your patch. I understand it for dequeue, but not for enqueue. I kept 'peek' there because the API still offers the 'peek' API capabilitie= s. I am also not sure on what 'peek' means for enqueue API. The enqueue 'pe= ek' 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 be= nefits. 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 mod= es: > > + * 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: >=20 > Comment should be "prepare enqueuing 32 objects" >=20 > > + * 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)); >=20 > Missing { } >=20 > > + * rte_ring_dequeue_sg_finish(ring, n); >=20 > Should be enqueue >=20 Thanks, will correct them. > > + * } > > + * > > + * 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; > > +}; >=20 > Would it be possible to simply return the offset instead of this structur= e? > The wrap could be managed by a __rte_ring_enqueue_elems() function. Trying to use __rte_ring_enqueue_elems() will force temporary copy. See bel= ow. >=20 > I mean something like this: >=20 > 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. > rte_ring_enqueue_sg_finish(ring, n); > } >=20 > 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. >=20 The alternate solution I can think of requires 3 things 1) the base address= of the ring 2) Index to where to copy 3) the mask. With these 3 things one= could 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 ca= re of wrap-around. } 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 to= calculate the actual address, worry about the wrap-around, second pointer = etc). The current approach hides some details and provides flexibility to the app= lication to use the pointer the way it wants. >=20 > Regards, > Olivier