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 51EEB42825; Thu, 23 Mar 2023 12:55:27 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2EA4A4021E; Thu, 23 Mar 2023 12:55:27 +0100 (CET) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 82D714021D for ; Thu, 23 Mar 2023 12:55:26 +0100 (CET) Content-class: urn:content-classes:message Subject: RE: [RFC 0/1] ring: add callback infrastructire to ring library MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Mar 2023 12:55:23 +0100 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D877FF@smartserver.smartshare.dk> X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <20230323113743.4086730-1-rory.sexton@intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RFC 0/1] ring: add callback infrastructire to ring library Thread-Index: Adlde+bOpN1UyFlFTkSweG9jOloYjQAAXv5A References: <20230323113743.4086730-1-rory.sexton@intel.com> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Rory Sexton" , , Cc: 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: Rory Sexton [mailto:rory.sexton@intel.com] > Sent: Thursday, 23 March 2023 12.38 >=20 > This is an RFC proposing the addition of a callback infrastructure to = the ring > library, particularly in the ring dequeue functions, but they could = also be > added to the enqueue functions if desired. >=20 > Callbacks in the ring dequeue functions would be beneficial for a = number of > reasons including but not limited to the following: > - would allow users to register specific functions to be called on = dequeue of > a > ring avoiding the need to call the function within application code = on > several > threads reading from said ring. > - would mirror the callback functionality offered by the ethdev = library for > threads that read exclusively from a ring and process packets based = off > that, > thus allowing for the same threads to read from either a NIC i/f or = directly > from a ring without needing a different codepath. >=20 > The addition of callbacks wouldn't impact the reading of rings by more = than 1 > cycle when no callbacks are registered. They could also additionally = be > compiled > in/out as desired to give more confidence in maintaining performance = when > callbacks are not required. On the condition that they can be omitted at build time, as you mention = here, I don't mind having more callbacks. >=20 > This RFC is to give a feel for what the additional APIs would be and = how they > would be integrated within the ring dequeue functions. As such only = function > declarations are present. If there is a willingness within the = community to > add > callback infrastructure to the ring library I will implement further = code. I like the idea that these callbacks mimic the ethdev callbacks, so if = proceeding with this, I think that both enqueue and dequeue callbacks = should be added. The ethdev callbacks share one = RTE_ETHDEV_RXTX_CALLBACKS define, so the ring callbacks can probably do = the same. >=20 > Rory Sexton (1): > ring: add infrastructure to allow callbacks within the ring library >=20 > lib/ring/rte_ring.h | 133 = ++++++++++++++++++++++++++++++++++++++- > lib/ring/rte_ring_core.h | 3 + > 2 files changed, 135 insertions(+), 1 deletion(-) >=20 > -- > 2.34.1 >=20