Message ID | 20230323113743.4086730-1-rory.sexton@intel.com (mailing list archive) |
---|---|
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2A0D042825; Thu, 23 Mar 2023 12:37:49 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BE8214021E; Thu, 23 Mar 2023 12:37:48 +0100 (CET) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by mails.dpdk.org (Postfix) with ESMTP id 9E4364021D for <dev@dpdk.org>; Thu, 23 Mar 2023 12:37:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1679571467; x=1711107467; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=Orj1CDuek1mVEGI6wFdY0I/EUVdml1fGDC50A0hgy7o=; b=POuGZ9yS7K0mCIxwbsCZX2PcG88YvCMtHxXnZbaZn4ULh7BhVEPf3e2W d+BliKSCGXCSipcE/MDd8GnGDjle3SQTnpZ8XnpqWtRes2roDh9XjSbah Ev6Q6IFc7S1bepkV1YxsCUD7Hv6RVxy4/xUZu7Avluc5mmK11Qmd7IbOg HQmZzv0bbM0VoqHM4zV3ohGTrjtcJKjyNQeyNYHEyJGYA1DjcEMWpLuEK KVClW8fuBMArsQTGVqoRFjfqUEaq0JsyqcG1DvkkU7uKGjCluMOZgxSsH iLtNioYXWa+mNwt5As2eHEZzPZCKd4Urr5CIxlGSAha52nof1FTJxyrp6 w==; X-IronPort-AV: E=McAfee;i="6600,9927,10657"; a="323310589" X-IronPort-AV: E=Sophos;i="5.98,283,1673942400"; d="scan'208";a="323310589" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Mar 2023 04:37:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10657"; a="806220479" X-IronPort-AV: E=Sophos;i="5.98,283,1673942400"; d="scan'208";a="806220479" Received: from silpixa00401024.ir.intel.com (HELO silpixa00401024.default.svc.cluster.local) ([10.237.223.91]) by orsmga004.jf.intel.com with ESMTP; 23 Mar 2023 04:37:45 -0700 From: Rory Sexton <rory.sexton@intel.com> To: honnappa.nagarahalli@arm.com, konstantin.v.ananyev@yandex.ru Cc: dev@dpdk.org, Rory Sexton <rory.sexton@intel.com> Subject: [RFC 0/1] ring: add callback infrastructire to ring library Date: Thu, 23 Mar 2023 11:37:42 +0000 Message-Id: <20230323113743.4086730-1-rory.sexton@intel.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 |
Series |
ring: add callback infrastructire to ring library
|
|
Message
Sexton, Rory
March 23, 2023, 11:37 a.m. UTC
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. 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. 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. 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. Rory Sexton (1): ring: add infrastructure to allow callbacks within the ring library lib/ring/rte_ring.h | 133 ++++++++++++++++++++++++++++++++++++++- lib/ring/rte_ring_core.h | 3 + 2 files changed, 135 insertions(+), 1 deletion(-)
Comments
> From: Rory Sexton [mailto:rory.sexton@intel.com] > Sent: Thursday, 23 March 2023 12.38 > > 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. > > 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. > > 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. > > 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. > > Rory Sexton (1): > ring: add infrastructure to allow callbacks within the ring library > > lib/ring/rte_ring.h | 133 ++++++++++++++++++++++++++++++++++++++- > lib/ring/rte_ring_core.h | 3 + > 2 files changed, 135 insertions(+), 1 deletion(-) > > -- > 2.34.1 >
Hi Roxy, Thanks for the work, few questions inline. > -----Original Message----- > From: Rory Sexton <rory.sexton@intel.com> > Sent: Thursday, March 23, 2023 6:38 AM > To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>; > konstantin.v.ananyev@yandex.ru > Cc: dev@dpdk.org; Rory Sexton <rory.sexton@intel.com> > Subject: [RFC 0/1] ring: add callback infrastructire to ring library > > 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. > > 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. I do not completely understand the 'avoiding the need to call the function within application code on several threads reading from said ring'. Irrespective of where the feature is implemented (either in ring library or the application), the call back function will be called on all the threads that receive from this queue. > - 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. Do you plan to support a chain of callbacks? > > 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. I would prefer to keep this feature on always as maintenance is easier. But, I think we should make that decision only after we have performance data. Is it possible to provide some performance data with this feature on but no callbacks registered? > > 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. > > Rory Sexton (1): > ring: add infrastructure to allow callbacks within the ring library > > lib/ring/rte_ring.h | 133 ++++++++++++++++++++++++++++++++++++++- > lib/ring/rte_ring_core.h | 3 + > 2 files changed, 135 insertions(+), 1 deletion(-) > > -- > 2.34.1
Hi Honnappa, Responses inline. I will continue with an initial implementation of this feature and capture performance data as suggested. Rgds, Rory > -----Original Message----- > From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> > Sent: Wednesday, April 5, 2023 1:46 AM > To: Sexton, Rory <rory.sexton@intel.com>; konstantin.v.ananyev@yandex.ru > Cc: dev@dpdk.org; nd <nd@arm.com>; nd <nd@arm.com> > Subject: RE: [RFC 0/1] ring: add callback infrastructire to ring library > > Hi Roxy, > Thanks for the work, few questions inline. > > > -----Original Message----- > > From: Rory Sexton <rory.sexton@intel.com> > > Sent: Thursday, March 23, 2023 6:38 AM > > To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>; > > konstantin.v.ananyev@yandex.ru > > Cc: dev@dpdk.org; Rory Sexton <rory.sexton@intel.com> > > Subject: [RFC 0/1] ring: add callback infrastructire to ring library > > > > 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. > > > > 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. > I do not completely understand the 'avoiding the need to call the function within application code on several threads reading from said ring'. Irrespective of where the feature is implemented (either in ring library or the application), the call back function will be called on all the threads that receive from this queue. I just mean the callback infrastructure would handle the call back function rather than developer needing to call their implemented function explicitely > > > - 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. > Do you plan to support a chain of callbacks? Yes I would plan to support a chain of callbacks > > > > > 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. > I would prefer to keep this feature on always as maintenance is easier. But, I think we should make that decision only after we have performance data. Is it possible to provide some performance data with this feature on but no callbacks registered? Agreed that keeping the feature always on would be easier long-term. I can capture performance data with the feature on but no callbacks registered. We can base the final implementation with that data in mind. > > > > > 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. > > > > Rory Sexton (1): > > ring: add infrastructure to allow callbacks within the ring library > > > > lib/ring/rte_ring.h | 133 ++++++++++++++++++++++++++++++++++++++- > > lib/ring/rte_ring_core.h | 3 + > > 2 files changed, 135 insertions(+), 1 deletion(-) > > > > -- > > 2.34.1
<snip> > > Hi Honnappa, > > Responses inline. > I will continue with an initial implementation of this feature and capture > performance data as suggested. > > Rgds, > Rory > > > -----Original Message----- > > From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> > > Sent: Wednesday, April 5, 2023 1:46 AM > > To: Sexton, Rory <rory.sexton@intel.com>; > > konstantin.v.ananyev@yandex.ru > > Cc: dev@dpdk.org; nd <nd@arm.com>; nd <nd@arm.com> > > Subject: RE: [RFC 0/1] ring: add callback infrastructire to ring > > library > > > > Hi Roxy, Sincere apologies for spelling your name incorrectly. > > Thanks for the work, few questions inline. > > > > > -----Original Message----- > > > From: Rory Sexton <rory.sexton@intel.com> > > > Sent: Thursday, March 23, 2023 6:38 AM > > > To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>; > > > konstantin.v.ananyev@yandex.ru > > > Cc: dev@dpdk.org; Rory Sexton <rory.sexton@intel.com> > > > Subject: [RFC 0/1] ring: add callback infrastructire to ring library > > > > > > 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. > > > > > > 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. > > I do not completely understand the 'avoiding the need to call the function > within application code on several threads reading from said ring'. > Irrespective of where the feature is implemented (either in ring library or the > application), the call back function will be called on all the threads that > receive from this queue. > I just mean the callback infrastructure would handle the call back function > rather than developer needing to call their implemented function explicitly Thanks for clarifying > > > <snip> > > > > > > > > > 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. > > I would prefer to keep this feature on always as maintenance is easier. But, I > think we should make that decision only after we have performance data. Is it > possible to provide some performance data with this feature on but no > callbacks registered? > Agreed that keeping the feature always on would be easier long-term. > I can capture performance data with the feature on but no callbacks > registered. > We can base the final implementation with that data in mind. Ack <snip>