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 0C20442A4F; Wed, 3 May 2023 15:32:35 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A51154114B; Wed, 3 May 2023 15:32:34 +0200 (CEST) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id F399941144 for ; Wed, 3 May 2023 15:32:32 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id 25EF420633; Wed, 3 May 2023 15:32:31 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [RFC PATCH] ring: adding TPAUSE instruction to ring dequeue X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 3 May 2023 15:32:27 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D878DD@smartserver.smartshare.dk> In-Reply-To: <20230503113840.11010-1-david.coyle@intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RFC PATCH] ring: adding TPAUSE instruction to ring dequeue Thread-Index: Adl9s+bv7RsCCwtFSLKbs1fiBp4buAABupZQ References: <20230503113840.11010-1-david.coyle@intel.com> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "David Coyle" , 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: David Coyle [mailto:david.coyle@intel.com] > Sent: Wednesday, 3 May 2023 13.39 >=20 > This is NOT for upstreaming. This is being submitted to allow early > comparison testing with the preferred solution, which will add TAPUSE > power management support to the ring library through the addition of > callbacks. Initial stages of the preferred solution are available at > http://dpdk.org/patch/125454. >=20 > This patch adds functionality directly to rte_ring_dequeue functions = to > monitor the empty reads of the ring. When a configurable number of > empty reads is reached, a TPAUSE instruction is triggered by using > rte_power_pause() on supported architectures. rte_pause() is used on > other architectures. The functionality can be included or excluded at > compilation time using the RTE_RING_PMGMT flag. If included, the new > API can be used to enable/disable the feature on a per-ring basis. > Other related settings can also be configured using the API. I don't understand why DPDK developers keep spending time on trying to = invent methods to determine application busyness based on entry/exit = points in a variety of libraries, when the application is in a much = better position to determine busyness. All of these "busyness measuring" = library extensions have their own specific assumptions and weird = limitations. I do understand that the goal is power saving, which certainly is = relevant! I only criticize the measuring methods. For reference, we implemented something very simple in our application = framework: 1. When each pipeline stage has completed a burst, it reports if it was = busy or not. 2. If the pipeline busyness is low, we take a nap to save some power. And here is the magic twist to this simple algorithm: 3. A pipeline stage is not considered busy unless it processed a full = burst, and is ready to process more packets immediately. This = interpretation of busyness has a significant impact on the percentage of = time spent napping during the low-traffic hours. This algorithm was very quickly implemented. It might not be perfect, = and we do intend to improve it (also to determine CPU Utilization on a = scale that the end user can translate to a linear interpretation of how = busy the system is). But I seriously doubt that any of the proposed = "busyness measuring" library extensions are any better. So: The application knows better, please spend your precious time on = something useful instead. @David, my outburst is not directed at you specifically. Generally, I do = appreciate experimenting as a good way of obtaining knowledge. So thank = you for sharing your experiments with this audience! PS: If cruft can be disabled at build time, I generally don't oppose to = it. -Morten