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.