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 82354A0524; Wed, 5 May 2021 12:05:40 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 02B2540040; Wed, 5 May 2021 12:05:40 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by mails.dpdk.org (Postfix) with ESMTP id 720E44003C for ; Wed, 5 May 2021 12:05:38 +0200 (CEST) IronPort-SDR: ymNLcnbcxjDT7F/s8rchMh4Rhp+KD5f5IQZ2n0LHXzdcmZBi4YpbIwg4cXIf6wskt36hDpjNAy y/j/qJuRWtzQ== X-IronPort-AV: E=McAfee;i="6200,9189,9974"; a="185644039" X-IronPort-AV: E=Sophos;i="5.82,274,1613462400"; d="scan'208";a="185644039" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 May 2021 03:05:36 -0700 IronPort-SDR: 9C30Bhi0DhP9DoZpCSwdsvlolTI/yzRuoxiBTQZSAFRrJo5EuJh8ph+jWFIzod06ekyX751vlC HdXaxzSbBAIg== X-IronPort-AV: E=Sophos;i="5.82,274,1613462400"; d="scan'208";a="433737723" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.20.224]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 05 May 2021 03:05:34 -0700 Date: Wed, 5 May 2021 11:05:31 +0100 From: Bruce Richardson To: David Marchand Cc: Harman Kalra , "kevin.laatz@intel.com" , "thomas@monjalon.net" , "stephen@networkplumber.org" , "dev@dpdk.org" , Luca Boccassi , Jerin Jacob Kollanukkaran Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] DPDK Telemetry library enhancement 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 Wed, May 05, 2021 at 10:57:37AM +0200, David Marchand wrote: > On Wed, May 5, 2021 at 9:49 AM Harman Kalra wrote: > > We have a use case where we need to gather statistics over network. Current implementation of telemetry library is based on Unix socket, we would like to enhance the scope of library to use network sockets. We understand security challenges with network sockets, to overcome them can we can think of two steps: > > 1. By default library will be using Unix sockets, it will be user decision to run library with network sockets by passing respective eal flags. > > 2. We can introduce some key/password authentication mechanism to the library, where only authorized clients can get connected to the server. Password can be passed by the user as eal flags, something similar to vf token which is uuid based. > > Kindly provide us suggestions/challenges over this enhancements. > > Rather than implement a new protocol, and code a new client, would > collectd fulfill your need? > > Info currently retrieved by the telemetry collecd plugin is hardwired. > Maybe some configuration could be added to this plugin for your new stats. > > > > > > One more query, can we register driver specific telemetry commands to collect driver stats? Is this upstream able? > > I don't remember a limitation/guideline on this subject. > Any command can be registered, this is up to the telemetry client to invoke it. > +1