From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <harry.van.haaren@intel.com> Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 58F1F5699 for <dev@dpdk.org>; Thu, 4 Oct 2018 15:25:59 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Oct 2018 06:25:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,338,1534834800"; d="scan'208";a="78682434" Received: from irsmsx152.ger.corp.intel.com ([163.33.192.66]) by orsmga008.jf.intel.com with ESMTP; 04 Oct 2018 06:25:52 -0700 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.67]) by IRSMSX152.ger.corp.intel.com ([169.254.6.110]) with mapi id 14.03.0319.002; Thu, 4 Oct 2018 14:25:51 +0100 From: "Van Haaren, Harry" <harry.van.haaren@intel.com> To: "Laatz, Kevin" <kevin.laatz@intel.com>, "dev@dpdk.org" <dev@dpdk.org> CC: "stephen@networkplumber.org" <stephen@networkplumber.org>, "gaetan.rivet@6wind.com" <gaetan.rivet@6wind.com>, "shreyansh.jain@nxp.com" <shreyansh.jain@nxp.com>, "thomas@monjalon.net" <thomas@monjalon.net>, "Richardson, Bruce" <bruce.richardson@intel.com> Thread-Topic: [PATCH v2 00/10] introduce telemetry library Thread-Index: AQHUWz+eJX4GKPxbOUKfYyMWY0UfzqUPCpJAgAAJrWA= Date: Thu, 4 Oct 2018 13:25:51 +0000 Message-ID: <E923DB57A917B54B9182A2E928D00FA65E2E6127@IRSMSX102.ger.corp.intel.com> References: <1535026093-101872-1-git-send-email-ciara.power@intel.com> <20181003173612.67101-1-kevin.laatz@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZTdiNjUwNTUtNjEzYy00Y2JlLWIzNDQtMDA2NTY0MzZkZjgyIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiT3MxdEVCRmNcL3NjMG16eXlWdW5ZVHlpQlFEaFVBSDRRbE83QUYyeWgwWVwveWptU1ZGd2JnREc4eHA5bkJBWHRQIn0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2 00/10] introduce telemetry library X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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> X-List-Received-Date: Thu, 04 Oct 2018 13:25:59 -0000 > -----Original Message----- > From: Van Haaren, Harry > Sent: Thursday, October 4, 2018 2:00 PM > To: Laatz, Kevin <kevin.laatz@intel.com>; dev@dpdk.org > Cc: stephen@networkplumber.org; gaetan.rivet@6wind.com; > shreyansh.jain@nxp.com; thomas@monjalon.net; Richardson, Bruce > <bruce.richardson@intel.com> > Subject: RE: [PATCH v2 00/10] introduce telemetry library >=20 > > -----Original Message----- > > From: Laatz, Kevin > > Sent: Wednesday, October 3, 2018 6:36 PM > > To: dev@dpdk.org > > Cc: Van Haaren, Harry <harry.van.haaren@intel.com>; > > stephen@networkplumber.org; gaetan.rivet@6wind.com; > shreyansh.jain@nxp.com; > > thomas@monjalon.net; Laatz, Kevin <kevin.laatz@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. >=20 > <snip> >=20 > > 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 >=20 >=20 > Hi Gaetan, Thomas, Stephen and Shreyansh! >=20 >=20 > goto TL_DR; // if time is short :) >=20 >=20 > In this v2 patchset, we've reworked the Telemetry to no longer use the vd= ev > infrastructure, instead having EAL enable it directly. This was requested= as > feedback to the v1 patchset. I'll detail the approach below, and highligh= t > some issues we identified while implementing it. >=20 > 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. >=20 > This patchset resolves that circular dependency by using a "weak" symbol = for > telemetry init, and then the "strong" version of telemetry init will repl= ace > it when the library is compiled in. Correction: we attempted this approach - but ended up adding a TAILQ of lib= rary 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 wo= n't > pull > in the Telemetry .so automatically... This means application-level build- > system > changes to enable --telemetry on the DPDK EAL command line. >=20 > Given the complexity in enabling EAL to handle the Telemetry init() and i= ts > dependencies, I'd like to ask you folks for input on how to better solve > this? >=20 >=20 > TL_DR; >=20 > I'll re-suggest the --vdev as an option. It might not be perfect, > but in my opinion it's a better solution than the v2 solution here... >=20 > Input and suggestions welcome, as you know integration is coming > close so sooner is better! >=20 >=20 > Regards, -Harry