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 52D10A04FA; Wed, 5 Feb 2020 16:21:51 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id AD4EF1C294; Wed, 5 Feb 2020 16:21:50 +0100 (CET) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) by dpdk.org (Postfix) with ESMTP id BA5571C24B for ; Wed, 5 Feb 2020 16:21:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1580916108; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2ZAZ440xHu792Eb4kdO0NVufABxICOlzg9YXHXBdqoI=; b=B9N0DQDkjBL0PkeyBvgT7bZ2udiR+DIiHdQz3ItIp3i8zA16HoIxD/POAczKPBkFwGGRcV 5FRiUqPWusQIiLsrqmMRvwhxVsNxdW0UswfL/nf/508JN0zJgjslcOhPHwQBWMZsq76xVX 1QrGJ35EegJ7ggYD4GlB05nCnyqinhg= Received: from mail-vk1-f198.google.com (mail-vk1-f198.google.com [209.85.221.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-161-B1G_uDgmP4mSy4zP68JYeA-1; Wed, 05 Feb 2020 10:21:28 -0500 Received: by mail-vk1-f198.google.com with SMTP id k129so724825vka.4 for ; Wed, 05 Feb 2020 07:21:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2ZAZ440xHu792Eb4kdO0NVufABxICOlzg9YXHXBdqoI=; b=JwJfhhSrnIMRSDFtFpeuD9Ew8XdTlaFYpxjmrniAQySNSgSK1taB17B+YJqDfwcM4s UpdmfCMoW/2KV9DaqSVe/Q8DLyv+VcoBUDFVnI2bqiesILjUALu/SRCM4hEn4nZkmnzy ZJktFznsCsOIDWrSNcsZC/Tz4BrJkuycnUMsfrEKHjUZ5dqjH2dAaebbu2GXvIUMcz2C SoVz+O1BcPrSBVwKxRC7oy6sTHM9N/nL55MFQYKYHE9nczT0mCt2eetTbRR8DYOKF/0D VCMdeJIXvhK/C1jlA96nuqxl51SGqEwtUZPz57AjWRrPGgcH7AqapBmEF0H7lugsxVP9 WRHw== X-Gm-Message-State: APjAAAVX/K0/zrsUDt+jt0cUAtrUwK4zlfRoVRFVBEvXKv1tGLzqfvSH hP1Za+6++wihrkJL7kgGJ1iLa24EHqqHJBUjn30/0oMeWqEE+uPwnolsFpsRJHHMDQw+Xb2Uq4e RgLmLRhFfx+is3fUSE20= X-Received: by 2002:a67:e342:: with SMTP id s2mr21713911vsm.198.1580916088249; Wed, 05 Feb 2020 07:21:28 -0800 (PST) X-Google-Smtp-Source: APXvYqyWjpBe5BQwFFVbhQFTTqPJ/Fq4DSiN+aKnlzi9QAElIT7kCWKLYGAaxmI/rMf+rP0bl+m77hqsr4vyg3zhz18= X-Received: by 2002:a67:e342:: with SMTP id s2mr21713886vsm.198.1580916087786; Wed, 05 Feb 2020 07:21:27 -0800 (PST) MIME-Version: 1.0 References: <20191205173128.64543-1-ciara.power@intel.com> In-Reply-To: <20191205173128.64543-1-ciara.power@intel.com> From: David Marchand Date: Wed, 5 Feb 2020 16:21:16 +0100 Message-ID: To: Ciara Power , Bruce Richardson Cc: dev , Emma Foley X-MC-Unique: B1G_uDgmP4mSy4zP68JYeA-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [RFC 0/6] replace telemetry with process_info 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 Ciara, Bruce, On Thu, Dec 5, 2019 at 6:34 PM Ciara Power wrote: > > From: Bruce Richardson > > This patchset proposes a new library, called "process-info" for now, to > replace the existing telemetry library in DPDK. (Name subject to change > if someone can propose a better one). > > The existing telemetry library provides useful capabilities if used: > - Creates a unix socket on the system to allow external programs > connect and gather stats about the DPDK process. > - Supports outputting the xstats for various network cards on the > system. > - Can be used to output any other information exported to the metrics > library, e.g. by applications. > - Uses JSON message format, which is widely supported by other > languages and systems. > - Is supported by a plugin to collectd. > > However, the library also has some issues and limitations that could be > improved upon: > - Has a dependency on libjansson for JSON processing, so is disabled > by default. > - Tied entirely to the metrics library for statistics. > - No support for sending non-stats data, e.g. something as simple as > DPDK version string. > - All data gathering functions are in the library itself, which also > means=E2=80=A6 > - No support for libraries or drivers to present their own > information via the library. > > We therefore propose to keep the good points of the existing library, > but change the way things work to rectify the downsides. > This leads to the following design choices in the library: > - Keep the existing idea of using a unix socket for connection (just > simplifying the connection handling). > - We would like to use JSON format, where possible, but the jansson > library dependency is problematic. However, creating JSON-encoded > data is easier than trying to parse JSON in C code, so we can keep > the JSON output format for processing by e.g. collectd and other > tools, while simplifying the input to be plain text commands: > - Commands in this RFC are designed to all start with "/" for > consistency > - Any parameters to the commands, e.g. the specific port to get > stats for, are placed after a comma "," > - Have the library only handle socket creation and input handling. > All data gathering should be provided by functions external to the > library registered by other components, e.g. have ethdev library > provide the function to query NIC xstats, etc. > - Have the library directly initialized by EAL by default, so that > unless an app explicitly does not want the support, monitoring is > available on all DPDK apps. > > The obvious question that remains to be answered here is: "why a new > library rather than just fixing the old one?" > > The answer is that we have conflicts between the final two design > choices above, which require that the library be built early in the > build as other libraries will call into it to register callbacks, and > the desire to keep backward compatibility e.g. for use with collectd > plugin, which requires the existing library code be kept around and > built - as it is now - at the end of the build process since it calls > into other DPDK libraries. We therefore cannot have one library that > meets both requirements, hence the replacement which allows us to > maintain backward compatibility by just leaving the old lib in place > until e.g. 20.11. > > This is also why the new library is called "process_info", since the > name "telemetry" is already taken. Suggestions for a better name > welcome. The only user of the rte_telemetry api I could find is the (not yet merged [1]) dpdk collectd plugin. How will this impact it? Can we expect compatibility? 1: https://github.com/collectd/collectd/pull/3273 --=20 David Marchand