From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id D0031A00C4; Sat, 16 Jul 2022 16:38:38 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9B6B340A87; Sat, 16 Jul 2022 16:38:37 +0200 (CEST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by mails.dpdk.org (Postfix) with ESMTP id 669E94021F for <dev@dpdk.org>; Sat, 16 Jul 2022 16:38:36 +0200 (CEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 11861320090D; Sat, 16 Jul 2022 10:38:32 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 16 Jul 2022 10:38:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; t=1657982312; x= 1658068712; bh=wgcjC9vfZasC89a1Fqp11FqJ9RFIRBGlu6NmbcwNk/I=; b=e M41ogKfC2vXC1ktv+TNk4Tev0n3tNlsSPIQiKXOhkKlUd3Y0nrQsZhcgP/S8pZwt 3bqeuDkt5xO695AnbtHuvdDM+1ZZby1YR1Ww4Ljj/Vxqk/s/S9HbU03R4jdItZY6 GC8xKc4lMJQsZgcJVjtuF+wx9QtEj6NtazA+ymSmU4T+LQ1V4AktAfrKFgrGzXKS olWZlfP5MxNt7KdKIidqw808rR4xRu27AraHuDCa40fwDYlN3Q2U0FqnF9bn2YqG 58QWa8EUuZHVc/7/AfC7MBJlvEQFIHVx/pSsa5ccCyg+l7Pnj2XvJINqQSoD6DBd u/EQcCuyiMyPM2Vpv24hw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1657982312; x= 1658068712; bh=wgcjC9vfZasC89a1Fqp11FqJ9RFIRBGlu6NmbcwNk/I=; b=K 49m5klYo3AFHr5IfK6t1PmP7kS5Xx+kdp6ngMt9RMXLL09PryOXt98Ctz+evwXkA qptqWwIwPxr42W9UyDg3e+1I9yDtzTlpezWGwocuB4OwzRoFqJ1cDDn+honrwqMr +qV+Vi+71wyzEO3R0ZGFhtiMal67h+BNeFQAZyws/Rd/8FZK6ol0CkB4oI5a3O2q JYA7DgVhhsB8xtsEkyp27jmVBAv7fPmZ4R63VzXCj0SK/oojIBZmeUkaPQUTwYvL 2ZqKoRX89T/w1MIEKzS4CW4XahIbrdVRCBF26UJ7UVp7idFFZ36lQ4iSmTkhYKQS DjB6bUlBmF92EalGv4gkg== X-ME-Sender: <xms:Z83SYuTGT-N1eoX1ZdmeuKQrvh3gLInyMIxqEYzoYImwCxUFbUhTQA> <xme:Z83SYjyjzs_b4CqsFUl5xsWwE6hjNPswB1uki9eZFchJb4HNOx0k0nsnp9EPLTmGW OrOsXoHIkweEswecg> X-ME-Received: <xmr:Z83SYr3AU5xYf_Pj0stos3QuwABSxQy6FGdTZS-A4hnJiZTjKxEFjjXcCG5FA8lwDPINNl0caYY2S-TH_as7ElFV5Q> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudekfedgkeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthhqredttddtudenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeefhfejleeuvdevtddutdeutdevhfeijeethfffueejhfetuddu vedtkedtieekffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: <xmx:Z83SYqBK8qesvHe5muAkAOIBplKa608BSX5TVmstBmuRyXYaHQmeug> <xmx:Z83SYnhK-fjfX2_KLrlZ94ColU-p8tVwVdHQW6MTaKDPh4A0YGY36A> <xmx:Z83SYmohkzI9h3VhbmiKIdzAbSbM2qAVkYQakMutish6xmp0sU7LoQ> <xmx:aM3SYk0f-5C_oS-zZygc5IJoJWhhT1Etio45nr9-OIrgNpskFd-Hyg> Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 16 Jul 2022 10:38:29 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: Anatoly Burakov <anatoly.burakov@intel.com>, Morten =?ISO-8859-1?Q?Br=F8rup?= <mb@smartsharesystems.com> Cc: dev@dpdk.org, Bruce Richardson <bruce.richardson@intel.com>, Nicolas Chautru <nicolas.chautru@intel.com>, Fan Zhang <roy.fan.zhang@intel.com>, Ashish Gupta <ashish.gupta@marvell.com>, Akhil Goyal <gakhil@marvell.com>, David Hunt <david.hunt@intel.com>, Chengwen Feng <fengchengwen@huawei.com>, Kevin Laatz <kevin.laatz@intel.com>, Ray Kinsella <mdr@ashroe.eu>, Ferruh Yigit <ferruh.yigit@xilinx.com>, Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>, Jerin Jacob <jerinj@marvell.com>, Sachin Saxena <sachin.saxena@oss.nxp.com>, Hemant Agrawal <hemant.agrawal@nxp.com>, Ori Kam <orika@nvidia.com>, Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>, Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>, Conor Walsh <conor.walsh@intel.com> Subject: Re: [PATCH v1 1/2] eal: add lcore busyness telemetry Date: Sat, 16 Jul 2022 16:38:27 +0200 Message-ID: <8128978.NyiUUSuA9g@thomas> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D871CC@smartserver.smartshare.dk> References: <24c49429394294cfbf0d9c506b205029bac77c8b.1657890378.git.anatoly.burakov@intel.com> <98CBD80474FA8B44BF855DF32C47DC35D871CC@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" 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 16/07/2022 00:13, Morten Br=F8rup: > > From: Anatoly Burakov [mailto:anatoly.burakov@intel.com] > > Sent: Friday, 15 July 2022 15.13 > >=20 > > Currently, there is no way to measure lcore busyness in a passive way, > > without any modifications to the application. This patch adds a new EAL > > API that will be able to passively track core busyness. > >=20 > > The busyness is calculated by relying on the fact that most DPDK API's > > will poll for packets. >=20 > This is an "alternative fact"! Only run-to-completion applications polls = for RX. Pipelined applications do not poll for packets in every pipeline st= age. >=20 > > Empty polls can be counted as "idle", while > > non-empty polls can be counted as busy. To measure lcore busyness, we > > simply call the telemetry timestamping function with the number of > > polls > > a particular code section has processed, and count the number of cycles > > we've spent processing empty bursts. The more empty bursts we > > encounter, > > the less cycles we spend in "busy" state, and the less core busyness > > will be reported. > >=20 > > In order for all of the above to work without modifications to the > > application, the library code needs to be instrumented with calls to > > the lcore telemetry busyness timestamping function. The following parts > > of DPDK are instrumented with lcore telemetry calls: > >=20 > > - All major driver API's: > > - ethdev > > - cryptodev > > - compressdev > > - regexdev > > - bbdev > > - rawdev > > - eventdev > > - dmadev > > - Some additional libraries: > > - ring > > - distributor > >=20 > > To avoid performance impact from having lcore telemetry support, a > > global variable is exported by EAL, and a call to timestamping function > > is wrapped into a macro, so that whenever telemetry is disabled, it > > only > > takes one additional branch and no function calls are performed. It is > > also possible to disable it at compile time by commenting out > > RTE_LCORE_BUSYNESS from build config. >=20 > Since all of this can be completely disabled at build time, and thus has = exactly zero performance impact, I will not object to this patch. >=20 > >=20 > > This patch also adds a telemetry endpoint to report lcore busyness, as > > well as telemetry endpoints to enable/disable lcore telemetry. > >=20 > > Signed-off-by: Kevin Laatz <kevin.laatz@intel.com> > > Signed-off-by: Conor Walsh <conor.walsh@intel.com> > > Signed-off-by: David Hunt <david.hunt@intel.com> > > Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com> > > --- > >=20 > > Notes: > > We did a couple of quick smoke tests to see if this patch causes > > any performance > > degradation, and it seemed to have none that we could measure. > > Telemetry can be > > disabled at compile time via a config option, while at runtime it > > can be > > disabled, seemingly at a cost of one additional branch. > >=20 > > That said, our benchmarking efforts were admittedly not very > > rigorous, so > > comments welcome! >=20 > This patch does not reflect lcore business, it reflects some sort of ingr= ess activity level. >=20 > All the considerations regarding non-intrusiveness and low overhead are g= ood, but everything in this patch needs to be renamed to reflect what it tr= uly does, so it is clear that pipelined applications cannot use this teleme= try for measuring lcore business (except on the ingress pipeline stage). +1 Anatoly, please reflect polling activity in naming. > It's a shame that so much effort clearly has gone into this patch, and no= one stopped to consider pipelined applications. :-( That's because no RFC was sent I think.