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 8E400A034F; Mon, 22 Feb 2021 16:10:13 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7B93240FDF; Mon, 22 Feb 2021 16:10:13 +0100 (CET) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mails.dpdk.org (Postfix) with ESMTP id D08DD4003C for ; Mon, 22 Feb 2021 16:10:11 +0100 (CET) IronPort-SDR: utVtAXZMvxRKpD4A9EEzgoMTfoTM1kuq05wRxnL4RYnZ6YCYcSmuL/fTvkeARf9E8r98+fB4UU VrZi0909Tfcw== X-IronPort-AV: E=McAfee;i="6000,8403,9902"; a="248529383" X-IronPort-AV: E=Sophos;i="5.81,197,1610438400"; d="scan'208";a="248529383" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2021 07:10:10 -0800 IronPort-SDR: WM/ctDeTC0XGsxHSG4WX2pnSv0wvC4tx5y3oxscvDN90TSENM4EZc6Bsvfh6hr6bRb2zk1u1fC I3C+3Fsi9E6A== X-IronPort-AV: E=Sophos;i="5.81,197,1610438400"; d="scan'208";a="402640285" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.232.118]) ([10.213.232.118]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Feb 2021 07:10:08 -0800 To: Hideyuki Yamashita , Thomas Monjalon Cc: dev@dpdk.org, Ciara Power , bruce.richardson@intel.com, david.hunt@intel.com, "Ma, Liang" , Stephen Hemminger , "Varghese, Vipin" , "Ananyev, Konstantin" , =?UTF-8?Q?Morten_Br=c3=b8rup?= References: <20201204075109.14694-1-yamashita.hideyuki@ntt-tx.co.jp> <3140511.LMxrbLn5pV@thomas> <20201222112257.CF9D.17218CA3@ntt-tx.co.jp> From: Ferruh Yigit X-User: ferruhy Message-ID: <5048abeb-d19b-6c4c-b7f0-c970b278d259@intel.com> Date: Mon, 22 Feb 2021 15:10:04 +0000 MIME-Version: 1.0 In-Reply-To: <20201222112257.CF9D.17218CA3@ntt-tx.co.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH 0/5] add apistats function 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 Sender: "dev" On 12/22/2020 2:22 AM, Hideyuki Yamashita wrote: > 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? > Hi Hideyuki, With current implementation the change will cause a performance degradation for all users, even if they use the stats or not. Even if the statics update wrapped with #ifdef, as suggested, the functionality is simple and it can be easily implemented by application using Rx/Tx callbacks, again as suggested, without introducing this new complexity. And for more complex usage, the jobstats already tries to provide a generic library for it, or application specific needs can be implemented in application level as done is l3fwd-power. Overall I agree the problem this patch is trying to solve is a valid one, but not sure about the current implementation, and I am marking current version as 'rejected', please feel free to send a new version with a new approach. Thanks, ferruh