From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 94443A09EF; Tue, 22 Dec 2020 03:23:37 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 05C27CA60; Tue, 22 Dec 2020 03:23:35 +0100 (CET) Received: from dish-sg.nttdocomo.co.jp (dish-sg.nttdocomo.co.jp [202.19.227.74]) by dpdk.org (Postfix) with ESMTP id 643CACA58 for ; Tue, 22 Dec 2020 03:23:32 +0100 (CET) X-dD-Source: Outbound Received: from zssg-mailmd103.ddreams.local (zssg-mailmd900.ddreams.local [10.160.172.63]) by zssg-mailou103.ddreams.local (Postfix) with ESMTP id 96C8F12011A; Tue, 22 Dec 2020 11:23:30 +0900 (JST) Received: from t131sg-mailcc112.ddreams.local (t131sg-mailcc112.ddreams.local [100.66.31.222]) by zssg-mailmd103.ddreams.local (dDREAMS) with ESMTP id <0QLP0142OYN6YTE0@dDREAMS>; Tue, 22 Dec 2020 11:23:30 +0900 (JST) Received: from t131sg-mailcc112.ddreams.local (localhost [127.0.0.1]) by t131sg-mailcc112.ddreams.local (unknown) with SMTP id 0BM2NUpR029135; Tue, 22 Dec 2020 11:23:30 +0900 Received: from zssg-mailmf103.ddreams.local (unknown [127.0.0.1]) by zssg-mailmf103.ddreams.local (Postfix) with ESMTP id 59B387E603B; Tue, 22 Dec 2020 11:23:09 +0900 (JST) Received: from zssg-mailmf103.ddreams.local (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 57C768E605E; Tue, 22 Dec 2020 11:23:09 +0900 (JST) Received: from localhost (unknown [127.0.0.1]) by IMSVA (Postfix) with SMTP id 4DBC28E605A; Tue, 22 Dec 2020 11:23:09 +0900 (JST) X-IMSS-HAND-OFF-DIRECTIVE: localhost:10026 Received: from zssg-mailmf103.ddreams.local (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4140F8E605C; Tue, 22 Dec 2020 11:23:08 +0900 (JST) Received: from zssg-mailua106.ddreams.local (unknown [10.160.172.62]) by zssg-mailmf103.ddreams.local (Postfix) with ESMTP; Tue, 22 Dec 2020 11:23:08 +0900 (JST) Received: from [10.87.198.18] (unknown [10.160.183.129]) by zssg-mailua106.ddreams.local (dDREAMS) with ESMTPA id <0QLP001G3YM91X40@dDREAMS>; Tue, 22 Dec 2020 11:22:58 +0900 (JST) Date: Tue, 22 Dec 2020 11:22:57 +0900 From: Hideyuki Yamashita In-reply-to: <3140511.LMxrbLn5pV@thomas> References: <20201204075109.14694-1-yamashita.hideyuki@ntt-tx.co.jp> <3140511.LMxrbLn5pV@thomas> Message-id: <20201222112257.CF9D.17218CA3@ntt-tx.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: Becky! ver. 2.75.01 [ja] X-TM-AS-GCONF: 00 To: Thomas Monjalon Cc: dev@dpdk.org, Ciara Power , bruce.richardson@intel.com, david.hunt@intel.com, "Ma, Liang" Subject: Re: [dpdk-dev] [PATCH 0/5] add apistats function X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hello, Thanks for your comments. Please see my comments inline tagged with [HY]. > 04/12/2020 08:51, Hideyuki Yamashita: > > In general, DPDK application consumes CPU usage because it polls > > incoming packets using rx_burst API in infinite loop. > > This makes difficult to estimate how much CPU usage is really > > used to send/receive packets by the DPDK application. > > > > For example, even if no incoming packets arriving, CPU usage > > looks nearly 100% when observed by top command. > > > > It is beneficial if developers can observe real CPU usage of the > > DPDK application. > > Such information can be exported to monitoring application like > > prometheus/graphana and shows CPU usage graphically. > > > > To achieve above, this patch set provides apistats functionality. > > apistats provides the followiing two counters for each lcore. > > - rx_burst_counts[RTE_MAX_LCORE] > > - tx_burst_counts[RTE_MAX_LCORE] > > Those accumulates rx_burst/tx_burst counts since the application starts. > > Please could you compare with what rte_jobstats offers? > http://code.dpdk.org/dpdk/latest/source/lib/librte_jobstats/rte_jobstats.h > > I feel all of this shares the same goals as librte_power work. [HY] Thanks for your commetns. You are correct. As you well know, l3fwd-power measures "how cpu cores are busy". And in that sense, the goal of my proposal is the same with yours . Moreover l3fwd-power is more precise than my proposal. Point of my proposal is - more easy to use - less code impact on application code I think that if application developer wants to need to measure "how cpu cores are busy" he/she will needs to implement - logic similar with l3fwd-power or - use jobstats API But it is rather heavy for existing applications. By using my proposal, it is "much easier" to implement. (But it is "rough" measurement. I think it is trade-off) How do you think about the idea? > [...] > > - basic API counting functionality(apistats) into librte_ethdev > > Could it be it be accessible via rte_telemetry? > http://code.dpdk.org/dpdk/latest/source/lib/librte_telemetry/rte_telemetry.h > [HY] OK. Currently, no reason not using telemetry. I think telemetry is useful for applications which does NOT call DPDK API(C lang API) directly. My patchset provide only C API to retrieve apistats. But if assuming not all applications call C API, then I think it is reasonable to add telemetry in addition to C API for exposing stats. Do you think "exposure via C API" is not needed? Thanks! BR, Hideyuki Yamashita NTT TechnoCross