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 DAB9E431E0; Mon, 23 Oct 2023 10:58:49 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C360C40270; Mon, 23 Oct 2023 10:58:49 +0200 (CEST) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id D0C3540262 for ; Mon, 23 Oct 2023 10:58:47 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id A79FF202CC; Mon, 23 Oct 2023 10:58:45 +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: [PATCH] eal: support lcore usage ratio X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 23 Oct 2023 10:58:42 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9EF6A@smartserver.smartshare.dk> In-Reply-To: <20231023040811.46038-1-fengchengwen@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] eal: support lcore usage ratio Thread-Index: AdoFZwAFee/MoibMRtqd8HiUeKhCJgAI5vYw References: <20231023040811.46038-1-fengchengwen@huawei.com> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Chengwen Feng" , , 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: Chengwen Feng [mailto:fengchengwen@huawei.com] > Sent: Monday, 23 October 2023 06.08 >=20 > Current, the lcore usage only display two key fields: busy_cycles and > total_cycles, which is inconvenient to obtain the usage ratio > immediately. So adds lcore usage ratio field. Usage ratio in percentage is only useful if it doesn't vary much over = time. Which use cases don't have a varying traffic pattern with busy = hours and off-peak hours? >=20 > Signed-off-by: Chengwen Feng > --- [...] > +static float > +calc_usage_ratio(const struct rte_lcore_usage *usage) > +{ > + return (usage->busy_cycles * 100.0) / (usage->total_cycles =3D=3D 0 = ? 1 : > usage->total_cycles); > +} This correctly prevents division by zero. If total_cycles by some freak = accident isn't updated, the result will be a very big number. You might = consider this alternative: return usage->total_cycles !=3D 0 ? (usage->busy_cycles * 100.0) / = usage->total_cycles : (float)0; > + > static int > lcore_dump_cb(unsigned int lcore_id, void *arg) > { > @@ -462,8 +468,9 @@ lcore_dump_cb(unsigned int lcore_id, void *arg) > /* Guard against concurrent modification of lcore_usage_cb. */ > usage_cb =3D lcore_usage_cb; > if (usage_cb !=3D NULL && usage_cb(lcore_id, &usage) =3D=3D 0) { > - if (asprintf(&usage_str, ", busy cycles %"PRIu64"/%"PRIu64, > - usage.busy_cycles, usage.total_cycles) < 0) { > + if (asprintf(&usage_str, ", busy cycles %"PRIu64"/%"PRIu64" > (ratio %.3f%%)", Is "%.3f%%" the community preference for human readable CPU usage = percentages? I prefer "%.02f%%", but don't object to the suggested format. NB: The format also applies to format_usage_ratio() below. > + usage.busy_cycles, usage.total_cycles, > + calc_usage_ratio(&usage)) < 0) { > return -ENOMEM; > } > } > @@ -511,11 +518,19 @@ struct lcore_telemetry_info { > struct rte_tel_data *d; > }; >=20 > +static void > +format_usage_ratio(char *buf, uint16_t size, const struct = rte_lcore_usage > *usage) > +{ > + float ratio =3D calc_usage_ratio(usage); > + snprintf(buf, size, "%.3f%%", ratio); > +}