From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail04.ics.ntt-tx.co.jp (mail05.ics.ntt-tx.co.jp [210.232.35.69]) by dpdk.org (Postfix) with ESMTP id 7F9531B39A for ; Thu, 22 Nov 2018 11:42:51 +0100 (CET) Received: from gwchk03.silk.ntt-tx.co.jp (gwchk03.silk.ntt-tx.co.jp [10.107.0.111]) by mail04.ics.ntt-tx.co.jp (unknown) with ESMTP id wAMAgokK004623; Thu, 22 Nov 2018 19:42:50 +0900 Received: (from root@localhost) by gwchk03.silk.ntt-tx.co.jp (unknown) id wAMAgo4k017779; Thu, 22 Nov 2018 19:42:50 +0900 Received: from gwchk.silk.ntt-tx.co.jp [10.107.0.110] by gwchk03.silk.ntt-tx.co.jp with ESMTP id VAA17778; Thu, 22 Nov 2018 19:42:50 +0900 Received: from imss06.silk.ntt-tx.co.jp (localhost [127.0.0.1]) by ccmail04.silk.ntt-tx.co.jp (unknown) with ESMTP id wAMAgodk005864; Thu, 22 Nov 2018 19:42:50 +0900 Received: from imss06.silk.ntt-tx.co.jp (localhost [127.0.0.1]) by imss06.silk.ntt-tx.co.jp (unknown) with ESMTP id wAMAgnNb022414; Thu, 22 Nov 2018 19:42:49 +0900 Received: from ccmail04 (smtp03.silk.ntt-tx.co.jp [10.107.0.135]) by imss06.silk.ntt-tx.co.jp (unknown) with SMTP id wAMAgnaS022411; Thu, 22 Nov 2018 19:42:49 +0900 Date: Thu, 22 Nov 2018 19:41:34 +0900 From: Hideyuki Yamashita In-Reply-To: <874cfe7e-e48f-ff90-9ad3-f57521386ec7@intel.com> References: <874cfe7e-e48f-ff90-9ad3-f57521386ec7@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.74 [ja] X-CCMail7: CC-Mail-V7.0.2-Client-Relayed Message-Id: <201811221042.wAMAgVIN005768@ccmail04.silk.ntt-tx.co.jp> X-TM-AS-MML: No X-CC-Mail-RelayStamp: CC-Mail-V5.14-Server To: "Laatz, Kevin" Cc: Ferruh Yigit , dev@dpdk.org, Harry Van Haaren , Bruce Richardson Subject: Re: [dpdk-dev] Question about telemetry on 18.11 release 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: , X-List-Received-Date: Thu, 22 Nov 2018 10:42:52 -0000 Hello Kevin, Thanks for your answering. Please see inline tagged with [Hideyuki]. > On 21/11/2018 11:38, Ferruh Yigit wrote: > > On 11/21/2018 7:48 AM, Hideyuki Yamashita wrote: > >> Hello, > >> > >> I have some basic questions about telemetry API > >> which is planned to be relaesed in 18.11. > >> > >> Note that I have read the follwoing document. > >> https://doc.dpdk.org/guides/howto/telemetry.html > >> > >> Q1. In general dpdk application use polling when > >> receiving packets. So CPU usage is always looks 100% > >> when measured using e.g. vmstat even if there is no packet receiving. > >> (CPU is busy for polling packets) > >> Is that correct? > This is a general DPDK question and not specific to telemetry. The above is correct, > it will always show as 100% busy. > >> > >> Q2. Is it correct understanding that dpdk application > >> can send "any" value(or metric) to client if client > >> requested via "telemetry" framework? > Correct, assuming the metrics are being collected in the metrics library. > The telemetry library grabs everything in the metrics library and sends > it to the client. If an application exposes its metrics to the metrics library, > then telemetry can pick this up. [Hideyuki] OK. Thanks. Now I think I understand. Both "metrics" and "telemetry" are framework to transmit information from its producer to consumer and that's all. Framework itself does NOT care about the content of the information. Right? > >> Q3.Is it possible to query "real cpu usage" from dpdk > >> application using "telemetry" framework? > >> ("real cpu usage" I mean if 0 pakcket incoming, > >> cpu usage indicates almost 0 %) > In short, no. The telemetry library only exposes what is available in the > metrics library. Getting the "real DPDK cpu usage" is very difficult in general. [Hideyuki] I would like to know the reason why getting "real DPDK cpu usage" is very difficult in general. I've learned there already exist mechanism like jobstats to get statistics of port and/or lcores. I thought that by combining those (jobstats,metrics,telemetry) it might be possible to get cpu usage. > >> Q4. Is it possible to inform client about fault or some > >> trouble from dpdk application? > > Telemetry can provide the metrics but doesn't have any monitoring > capabilities in terms of alerting the client of, let's say, an enormous burst > of dropped packets. The telemetry library is purely a mechanism to transport > metrics from DPDK to an external client. It is up to the client to interpret > these metrics. [Hideyuki] Thanks for your information. I understand that using metrics/telemetry, client can get information about burst, dropped packets and is able to assume "there is a fault" if the client is smart enough. BTW are there any mechanism in dpdk library to detect fault of dpdk application except metrics/telemetry? Thanks! BR, Hideyuki Yamashita NTT TechnoCross > >> Background I ask above is that > >> - I am relative new to DPDK world and have almost no knowledge about > >> "telemetry" > >> - I am interested in how dpdk applications can "scales" on platform > >> like OpenStack. I think some mesurement mechanism required > >> and I thought it might be "telemetry" APIs. > > Briefly I think yes, telemetry can be measurement mechanism and interface to > > external application. Cc'ed Harry & Kevin for more detailed answers. > > > >> Thanks in advance. > >> > >> BR, > >> Hideyuki Yamashita > >> NTT TechnoCross > >> > >>