From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id C6792A0524; Wed, 5 May 2021 12:15:09 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4B50540143; Wed, 5 May 2021 12:15:09 +0200 (CEST) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) by mails.dpdk.org (Postfix) with ESMTP id 21EEA40040 for <dev@dpdk.org>; Wed, 5 May 2021 12:15:07 +0200 (CEST) Received: by mail-io1-f52.google.com with SMTP id t3so1158396iol.5 for <dev@dpdk.org>; Wed, 05 May 2021 03:15:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=x1BF+WdXkxwvnRjJ7qq05aByBMdgMAOtFZnVbrukQdk=; b=QOp6X+AfndSU6vjg5MmD70vX+KOuYe4OpeCio1l2ms1Z+nDTsqh9jmMg9R3Cx9Ufew DmMc53kLv6gGG3oEOhZj0d4RtGZKAbReQty7SEsVC6toSiKhxC3aMKcT6IrQL6ietYA1 rUMFLVu8zyzxaaunGpA91Jhq30MyhxbDICl+aGUJvHnQvGFqpLT9KwKfag1rcAuHEtEV Ob5UUXUy89bTdL0Ys8OrFOAT7tVn2bEnRjuKk/AS05PuV0Y+ia6CylEUsc3XBYsmCkTR kNQwBSwiYOTwA4xR7Zgh1n3k2IjBW7IoUwNoToyCc6FUe2Op+YanrPXEpK/x97dwHkKb qFCA== 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=x1BF+WdXkxwvnRjJ7qq05aByBMdgMAOtFZnVbrukQdk=; b=iOHDIlfj4g48HfVTsZBrzrw9ybM7bUfAziT5dLV8i0mBd9/d+hzExVBjf0u4tlU0a6 Et1GXOTALIYt5toTPRqALgX8WYaqIVMSzB5fO3pyyOA+hip+2LD7qvCoHJcDn3T0fJ61 JhS7WCG9c/5RBYCj1K46cghs95JH6SwZ+dqNYXgk8m62cGdBwB3knh7XBemQ7sn6Zth+ 7nH7Wi+rmFktnS/rUS1svVj0z2CKe3iDZJW3BMrT/vU/XXu/o+/p6vfVIdYSwr3OulHc 6mR1yNAZuYjtYaAZgjpTxDDfTi33glVS0fbOlD134KbLTLfA++IFqJGZx9HdOz6vA+2Q bE0Q== X-Gm-Message-State: AOAM533u6GFP5254SiRXYujQfLCroAHe6B5crR/SsOJx/6noZ+5O1M9K +bjhQuPeIiyrqEWwa3R7yhB27d1vTBHJVrvj2n4= X-Google-Smtp-Source: ABdhPJwKrnU9BPzruFew7TgU4bkavsyuk6F4HVCs5WgoZAeWqmufiEfrPG59uD5TPndKVWVXHJlDfPbv5P44DElNBps= X-Received: by 2002:a5d:9c9a:: with SMTP id p26mr8547851iop.94.1620209706449; Wed, 05 May 2021 03:15:06 -0700 (PDT) MIME-Version: 1.0 References: <BN9PR18MB42041A43A2481A77E3C947F2C5599@BN9PR18MB4204.namprd18.prod.outlook.com> <8309999.7OePmkgMO5@thomas> <CALBAE1M05btbf-pe-V5zOurQ2E223yh-v06giq7jkdZzKjAyXg@mail.gmail.com> <YJJs8XEuDZ93+p6d@bricha3-MOBL.ger.corp.intel.com> In-Reply-To: <YJJs8XEuDZ93+p6d@bricha3-MOBL.ger.corp.intel.com> From: Jerin Jacob <jerinjacobk@gmail.com> Date: Wed, 5 May 2021 15:44:50 +0530 Message-ID: <CALBAE1PT_M8mc=zV6A40KbObf5Y2Ty7s4BMs_NvEE7YbdUU=-A@mail.gmail.com> To: Bruce Richardson <bruce.richardson@intel.com> Cc: Thomas Monjalon <thomas@monjalon.net>, Harman Kalra <hkalra@marvell.com>, "kevin.laatz@intel.com" <kevin.laatz@intel.com>, David Marchand <david.marchand@redhat.com>, "stephen@networkplumber.org" <stephen@networkplumber.org>, "dev@dpdk.org" <dev@dpdk.org>, Luca Boccassi <bluca@debian.org>, Jerin Jacob <jerinj@marvell.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> On Wed, May 5, 2021 at 3:31 PM Bruce Richardson <bruce.richardson@intel.com> wrote: > > On Wed, May 05, 2021 at 03:07:02PM +0530, Jerin Jacob wrote: > > On Wed, May 5, 2021 at 2:13 PM Thomas Monjalon <thomas@monjalon.net> wr= ote: > > > > > > 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 wo= uld like to enhance the scope of library to use network sockets. We underst= and security challenges with network sockets, to overcome them can we can t= hink of two steps: > > > > 1. By default library will be using Unix sockets, it will be user d= ecision to run library with network sockets by passing respective eal flags= . > > > > 2. We can introduce some key/password authentication mechanism to t= he 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 to= ken 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 I think, the purpose of zeromq is to unify the different transport mechanisms to avoid multiple code path for different transport.IMHO, at some point in time it needs to unify. > 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 proce= ss > and for which the local unix interface may be as good. Collectd has zeromq plugin for transport[1]. So, I think, we can meet that use case too with zeromq [1] https://collectd.org/wiki/index.php/Plugin:ZeroMQ > > /Bruce