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 0981442A50; Wed, 3 May 2023 16:51:26 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 898B04114B; Wed, 3 May 2023 16:51:25 +0200 (CEST) Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) by mails.dpdk.org (Postfix) with ESMTP id 1B37B41144 for ; Wed, 3 May 2023 16:51:23 +0200 (CEST) Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-1aaf70676b6so28087765ad.3 for ; Wed, 03 May 2023 07:51:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20221208.gappssmtp.com; s=20221208; t=1683125483; x=1685717483; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=yKBlhaI7GzTZNHY2B4RTgoOvg4rSFzBlUlRVAwoIVJ0=; b=b3Xf3O0b0hdg9dK9vSBgDDBlxudNZf4yJodw2nbSq+PQ773rKFgszTgP+wKlsFOrf8 b25QT+kKwaE41ogc5VxMLuhJ+qX+9H4MTt1/+yXQMFQg499sJXm+Su0r93tCFD8b2iZB 26mcYfhwDjeAhujuOMcg/llGTJBtusVcqaRSzd3ziCETEpkxoYlODiCuVvVnZ1Z40SXa xY2ES2cGiuYSR6bFfUbbVx9jjNKeVN641ZUfAsmmaODnHa0lmyaGFP9pzBQXiYYPQx8O O+2IkqaGkAqcsZ9achErG66KQYYAiiZuzYO106xb9NmNylOci8Dfk6b3jtBktfWK1sib +7Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683125483; x=1685717483; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=yKBlhaI7GzTZNHY2B4RTgoOvg4rSFzBlUlRVAwoIVJ0=; b=RoBE98tRiZImmcPL21gXiYhxEoGXoL8yhmhDl90bXWROb1AVJzi9tKPFixzvSAA7NB pVJ9VQymNDRZvHpV62Dz1sDn69abjjSupiwjzSo5ustUMMtlQpa+EJiLIR2VLOYwPo90 HiWawpLRK9t0z1QxySTggBh/QdXCyg/VQHUtMVWhg/eHpMVAjonxSRWjWUUfLKGzFrVd U/NsJOCzoTwjEhnFBV1I/Ydpv8xaqgLwewg7l0gRVgLoHi9V4x5B8kNlSWJ3BmR8mQcc xDw8lwDXjtA1bY6jj8IIHCwdAtNtxiVVBRYxX0flbtiYuboRsWB2Aj5niZvae0w/O9mo ycgA== X-Gm-Message-State: AC+VfDzHt+yGBjGekGl6R+m1OT19Vr7k/hlidgY4QQgHk9gqJ60AkdyI 0y/eDhmAr/+/oY2ahhsNm8PDQQ== X-Google-Smtp-Source: ACHHUZ5TI2J2jKmfhhPK+4gQr4DpV2/5IrcwfKdNZjg2yVerDFuCSCcZrF4WLIEMFpBlYhJyznU5fQ== X-Received: by 2002:a17:903:22c9:b0:1a5:22a6:4e6a with SMTP id y9-20020a17090322c900b001a522a64e6amr260311plg.51.1683125482923; Wed, 03 May 2023 07:51:22 -0700 (PDT) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id f3-20020a170902ce8300b001a1d41d1b8asm11157270plg.194.2023.05.03.07.51.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 May 2023 07:51:22 -0700 (PDT) Date: Wed, 3 May 2023 07:51:20 -0700 From: Stephen Hemminger To: Morten =?UTF-8?B?QnLDuHJ1cA==?= Cc: "David Coyle" , , , , Subject: Re: [RFC PATCH] ring: adding TPAUSE instruction to ring dequeue Message-ID: <20230503075120.04b43569@hermes.local> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D878DD@smartserver.smartshare.dk> References: <20230503113840.11010-1-david.coyle@intel.com> <98CBD80474FA8B44BF855DF32C47DC35D878DD@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 On Wed, 3 May 2023 15:32:27 +0200 Morten Br=C3=B8rup wrote: > > 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. =20 >=20 > I don't understand why DPDK developers keep spending time on trying to in= vent methods to determine application busyness based on entry/exit points i= n a variety of libraries, when the application is in a much better position= to determine busyness. All of these "busyness measuring" library extension= s have their own specific assumptions and weird limitations. >=20 > I do understand that the goal is power saving, which certainly is relevan= t! I only criticize the measuring methods. >=20 > For reference, we implemented something very simple in our application fr= amework: > 1. When each pipeline stage has completed a burst, it reports if it was b= usy or not. > 2. If the pipeline busyness is low, we take a nap to save some power. >=20 > And here is the magic twist to this simple algorithm: > 3. A pipeline stage is not considered busy unless it processed a full bur= st, and is ready to process more packets immediately. This interpretation o= f busyness has a significant impact on the percentage of time spent napping= during the low-traffic hours. >=20 > 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 t= hat the end user can translate to a linear interpretation of how busy the s= ystem is). But I seriously doubt that any of the proposed "busyness measuri= ng" library extensions are any better. >=20 > So: The application knows better, please spend your precious time on some= thing useful instead. Agree, with Morten. This is not the place to add more code. Does this have an applicable use case to common DPDK applications like OVS,= VPP, or even Contrail? Or is it some intern experiment kind of thing. The existing l3fwd is an example of how to do PM in application. Switching = to interrupt mode lets the kernel help out. And the kernel will no how to handle multicore etc. > @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! >=20 > PS: If cruft can be disabled at build time, I generally don't oppose to i= t. Cruft increases test coverage surface, creates technical debt, and makes Li= nux distro maintainers upset.