On Wed, May 5, 2021 at 2:13 PM Thomas Monjalon <tho...@monjalon.net> 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/ 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 > > It reminds me this discussion for IF proxy: > http://inbox.dpdk.org/dev/2580933.jp2sp48Hzj@xps/ > > > > > One more query, can we register driver specific telemetry commands to > > collect driver stats? Is this upstream able? > > >
