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 A34A3A00C2; Thu, 23 Apr 2020 12:30:40 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DC0551D408; Thu, 23 Apr 2020 12:30:39 +0200 (CEST) Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by dpdk.org (Postfix) with ESMTP id D0E9E1D177 for ; Thu, 23 Apr 2020 12:30:37 +0200 (CEST) Received: by mail-wr1-f65.google.com with SMTP id j1so6227475wrt.1 for ; Thu, 23 Apr 2020 03:30:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:user-agent:mime-version; bh=uNCFEciMtdTwdVaxetCsQFTrm0Unxw2kNLvcjHg3IHE=; b=Wv9PkzgAXSlISUiYth1WDbvN+cezMWVYi+KsercYM3u6nJdgh/0Im0UMB7CG4wRkyX t3QrLdFBhxGWeSAd0qEVAWLvFw5E0CtaCs70MUUFsuwCKMaIByFFGShDUdk+kEsNNzFv Fp73vTBY71Sb08QmU2lbtfDCTia0w/qRZ/ms2Y4Z0wGGQAngwhbKybGVmoJUEplW+pXk DaAX/KhMqFTvqnrev3ukgXZixLBKpsEmX1nR5WLdcvHC2rjXHrD4b3tOjRkOGIuJ8bw6 2eT6p3n9th+Pwa5Fa/KrpTRwSRaVKC0vjkOC+iAkqYZHXhBipCZbdT/pQLkwxJGnpJPX VyRg== X-Gm-Message-State: AGi0PuYhioJGKHywCH1/L1G9bV7TZLmzmwE1RI34pgkqDVKGqlGQ1umW ppxiahsyADP8VcXY5SryWwQ= X-Google-Smtp-Source: APiQypIhN+oTtsBuQT5U3qtYDkusC8XGIROoK941jTZWrgNuI+7j8QBbecf1peKM1hGHyud6rX4Z8Q== X-Received: by 2002:a05:6000:1242:: with SMTP id j2mr4103796wrx.274.1587637837567; Thu, 23 Apr 2020 03:30:37 -0700 (PDT) Received: from localhost ([2a01:4b00:f419:6f00:7a8e:ed70:5c52:ea3]) by smtp.gmail.com with ESMTPSA id k14sm3148810wrp.53.2020.04.23.03.30.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Apr 2020 03:30:36 -0700 (PDT) Message-ID: From: Luca Boccassi To: Thomas Monjalon , Bruce Richardson Cc: Ciara Power , dev@dpdk.org, kevin.laatz@intel.com, reshma.pattan@intel.com, jerinjacobk@gmail.com, david.marchand@redhat.com, keith.wiles@intel.com, mb@smartsharesystems.com Date: Thu, 23 Apr 2020 11:30:35 +0100 In-Reply-To: <8682539.rMLUfLXkoz@thomas> References: <20200319171907.60891-1-ciara.power@intel.com> <2104953.NgBsaNRSFp@thomas> <20200409091909.GC605@bricha3-MOBL.ger.corp.intel.com> <8682539.rMLUfLXkoz@thomas> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2 00/16] update and simplify telemetry library. 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" On Thu, 2020-04-09 at 11:37 +0200, Thomas Monjalon wrote: > 09/04/2020 11:19, Bruce Richardson: > > On Wed, Apr 08, 2020 at 08:03:26PM +0200, Thomas Monjalon wrote: > > > 08/04/2020 18:49, Ciara Power: > > > > This patchset extensively reworks the telemetry library adding new > > > > functionality and simplifying much of the existing code, while > > > > maintaining backward compatibility. > > > >=20 > > > > This work is based on the previously sent RFC for a "process info" > > > > library: https://patchwork.dpdk.org/project/dpdk/list/?series=3D774= 1 > > > > However, rather than creating a new library, this patchset takes > > > > that work and merges it into the existing telemetry library, as > > > > mentioned above. > > > >=20 > > > > The telemetry library as shipped in 19.11 is based upon the metrics > > > > library and outputs all statistics based on that as a source. Howev= er, > > > > this limits the telemetry output to only port-level statistics > > > > information, rather than allowing it to be used as a general scheme= for > > > > telemetry information across all DPDK libraries. > > > >=20 > > > > With this patchset applied, rather than the telemetry library being > > > > responsible for pulling ethdev stats and pushing them into the metr= ics > > > > library for retrieval later, each library e.g. ethdev, rawdev, and = even > > > > the metrics library itself (for backwards compatiblity) now handle = their > > > > own stats. Any library or app can register a callback function wit= h > > > > telemetry, which will be called if requested by the client connecte= d via > > > > the telemetry socket. The callback function in the library/app then > > > > formats its stats, or other data, into a JSON string, and returns i= t to > > > > telemetry to be sent to the client. > > >=20 > > > I think this is a global need in DPDK, and it is usually called RPC, > > > IPC or control messaging. > > > We had a similar need for multi-process communication, thus rte_mp IP= C. > > > We also need a control channel for user configuration applications. > > > We also need to control some features like logging or tracing. > > >=20 > > > In my opinion, it is time to introduce a general control channel in D= PDK. > > > The application must be in the loop of the control mechanism. > > > Making such channel standard will ease application adoption. > > >=20 > > > Please read some comments here: > > > http://inbox.dpdk.org/dev/2580933.jp2sp48Hzj@xps/ > > >=20 > > Hi Thomas, > >=20 > > I agree that having a single control mechanism or messaging mechanism i= n > > DPDK would be nice to have. However, I don't believe the plans for such= a > > scheme should impact this patchset right now as the idea of a common > > channel was only first mooted about a week ago, and while there has bee= n > > some email discussion about it, there is as yet no requirements list th= at > > I've seen, nobody actually doing coding work on it, no rfc and most > > importantly no timeline for creating and merging such into DPDK. >=20 > Yes, this is a new idea. > Throwing the idea in this "telemetry" thread and in "IF proxy" thread > is the first step before starting a dedicated thread to design > a generic mechanism. May I offer the services of https://zeromq.org/ ? --=20 Kind regards, Luca Boccassi