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 8A105A0524; Wed, 5 May 2021 12:01:31 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6BCDA40040; Wed, 5 May 2021 12:01:31 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by mails.dpdk.org (Postfix) with ESMTP id CA46E4003C for ; Wed, 5 May 2021 12:01:29 +0200 (CEST) IronPort-SDR: +/qAv97doDQcI2Z1/8Z8OWMvsGMd34Ucm2Fi+Lc/L9ySSeyEd8KNvGY3LGEjuBObUiYlxyDrDP ABFucxyx4t1w== X-IronPort-AV: E=McAfee;i="6200,9189,9974"; a="259455830" X-IronPort-AV: E=Sophos;i="5.82,274,1613462400"; d="scan'208";a="259455830" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 May 2021 03:01:28 -0700 IronPort-SDR: PSF61Rt6NwrUH5Mhiq8pbq3znaANtZ1PGCkw+saXEJNhQMXNkM0YroqhXlBSlV3NboKejuyOUf AOCQGm7yTnJg== X-IronPort-AV: E=Sophos;i="5.82,274,1613462400"; d="scan'208";a="433736314" 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:01:25 -0700 Date: Wed, 5 May 2021 11:01:21 +0100 From: Bruce Richardson To: Jerin Jacob Cc: Thomas Monjalon , Harman Kalra , "kevin.laatz@intel.com" , David Marchand , "stephen@networkplumber.org" , "dev@dpdk.org" , Luca Boccassi , Jerin Jacob Message-ID: References: <8309999.7OePmkgMO5@thomas> 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 03:07:02PM +0530, Jerin Jacob wrote: > On Wed, May 5, 2021 at 2:13 PM Thomas Monjalon wrote: > > > > 05/05/2021 09:49, Harman Kalra: > > > Hi All, > > > > > > 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. > > > > Not sure it should be part of the telemetry lib. > > In any case, when implementing network communication, > > I encourage you to look at ZeroMQ. > > ZeroMQ is a good option for Transport to hide the underlying transport > variants like In-process, Intra-process, TCP. > Also, it has various different options for security backend like > http://curvezmq.org/ > Sounds reasonable - I'm in favour of any scheme that means that we don't need to implement out own authentication or security mechanisms for this. > if we pick ZeroMQ for transport then it will translate to > > 1) Remove unix file socket from telemetry > 2) Use ZeroMQ for local and remote messaging > 3) Needs to make telemetry or dpdk depends on ZeroMQ library(Since > telemetry is experimental, I hope, we can change this) > > Thoughts from others including telemetry maintainers > I'd like to keep the existing Unix socket around, as well as any extra zeromq interface, rather than replacing one with the other. Then rather than introducing a hard dependency on zeromq, it can be an optional one, where support is compiled in if available. There may be monitoring applications such as collectd, which run their own local monitoring process and for which the local unix interface may be as good. /Bruce