[dpdk-dev] [PATCH v2 00/10] introduce telemetry library

Gaëtan Rivet gaetan.rivet at 6wind.com
Thu Oct 4 17:16:49 CEST 2018


Hi Harry,

On Thu, Oct 04, 2018 at 01:25:51PM +0000, Van Haaren, Harry wrote:
> > -----Original Message-----
> > From: Van Haaren, Harry
> > Sent: Thursday, October 4, 2018 2:00 PM
> > To: Laatz, Kevin <kevin.laatz at intel.com>; dev at dpdk.org
> > Cc: stephen at networkplumber.org; gaetan.rivet at 6wind.com;
> > shreyansh.jain at nxp.com; thomas at monjalon.net; Richardson, Bruce
> > <bruce.richardson at intel.com>
> > Subject: RE: [PATCH v2 00/10] introduce telemetry library
> > 
> > > -----Original Message-----
> > > From: Laatz, Kevin
> > > Sent: Wednesday, October 3, 2018 6:36 PM
> > > To: dev at dpdk.org
> > > Cc: Van Haaren, Harry <harry.van.haaren at intel.com>;
> > > stephen at networkplumber.org; gaetan.rivet at 6wind.com;
> > shreyansh.jain at nxp.com;
> > > thomas at monjalon.net; Laatz, Kevin <kevin.laatz at intel.com>
> > > Subject: [PATCH v2 00/10] introduce telemetry library
> > >
> > > This patchset introduces a Telemetry library for DPDK Service Assurance.
> > > This library provides an easy way to query DPDK Ethdev metrics.
> > 
> > <snip>
> > 
> > > Note: We are aware that the --telemetry flag is not working for meson
> > > builds, we are working on it for a future patch.  Despite opterr being set
> > > to 0, --telemetry said to be 'unrecognized' as a startup print. This is a
> > > cosmetic issue and will also be addressed.
> > >
> > > ---
> > > v2:
> > >    - Reworked telemetry as part of EAL instead of using vdev (Gaetan)
> > >    - Refactored rte_telemetry_command (Gaetan)
> > >    - Added MAINTAINERS file entry (Stephen)
> > >    - Updated docs to reflect vdev to eal rework
> > >    - Removed collectd patch from patchset (Thomas)
> > >    - General code clean up from v1 feedback
> > 
> > 
> > Hi Gaetan, Thomas, Stephen and Shreyansh!
> > 
> > 
> > goto TL_DR; // if time is short :)
> > 
> > 
> > In this v2 patchset, we've reworked the Telemetry to no longer use the vdev
> > infrastructure, instead having EAL enable it directly. This was requested as
> > feedback to the v1 patchset. I'll detail the approach below, and highlight
> > some issues we identified while implementing it.
> > 
> > Currently, EAL does not depend on any "DPDK" libraries (ignore kvargs etc
> > for a minute).
> > Telemetry is a DPDK library, so it depends on EAL. In order to have EAL
> > initialize
> > Telemetry, it must depend on it - this causes a circular dependency.
> > 
> > This patchset resolves that circular dependency by using a "weak" symbol for
> > telemetry init, and then the "strong" version of telemetry init will replace
> > it when the library is compiled in.
> 
> Correction: we attempted this approach - but ended up adding a TAILQ of library
> initializers functions to EAL, which was then iterated during rte_eal_init().
> This also resolved the circular-dependency, but the same linking issue as
> described below still exists.
> 
> So - the same question still stands - what is the best solution for 18.11?
> 
> 
> > Although this *technically* works, it
> > requires
> > that applications *LINK* against Telemetry library explicitly - as EAL won't
> > pull
> > in the Telemetry .so automatically... This means application-level build-
> > system
> > changes to enable --telemetry on the DPDK EAL command line.
> > 
> > Given the complexity in enabling EAL to handle the Telemetry init() and its
> > dependencies, I'd like to ask you folks for input on how to better solve
> > this?
> > 

I think the v2 is better. I have suggested a few changes, but I think
you almost have a final version.

Is it not possible to use -d or to put the .so in the solib_dir?
If you have symbols to solve at link-time, then you have already
modified you app anyway (doesn't concern rte_telemetry, but for general
lib consideration). If not, you can ask EAL to load it dynamically, so
it should be ok?

Sorry, none of our clients are using DPDK in shared mode, I'm not
familiar with the process here. But I'm convinced that libs
should not subvert PMD facilities to get their way, and if something is
missing it could be useful to other libraries as well, so it might as
well be cleanly handled.

-- 
Gaëtan Rivet
6WIND


More information about the dev mailing list