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 42F7EA054F; Tue, 2 Mar 2021 12:18:14 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 03F2C4014E; Tue, 2 Mar 2021 12:18:14 +0100 (CET) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by mails.dpdk.org (Postfix) with ESMTP id EFB5F40142 for ; Tue, 2 Mar 2021 12:18:12 +0100 (CET) IronPort-SDR: JJy4yFxgWDPOXsOzFCQxU9WUAq9TJZT8kr4hvRRihC1s06/aIwpPQ+hGJPhpT3nF/5/J9/rLSw YrH0gUpdpSdw== X-IronPort-AV: E=McAfee;i="6000,8403,9910"; a="166016051" X-IronPort-AV: E=Sophos;i="5.81,216,1610438400"; d="scan'208";a="166016051" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Mar 2021 03:18:12 -0800 IronPort-SDR: c4b9L8Oesi1dafhdU8NX4k8G4v1DMkMys/+xwdasrHwUgYXbZF8GTrL5bIzBWH//1MdvfRnCIg ++K/RASTsKMQ== X-IronPort-AV: E=Sophos;i="5.81,216,1610438400"; d="scan'208";a="398964226" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.19.13]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 02 Mar 2021 03:18:10 -0800 Date: Tue, 2 Mar 2021 11:18:06 +0000 From: Bruce Richardson To: Thomas Monjalon Cc: Kevin Laatz , ciara.power@intel.com, dev@dpdk.org, david.marchand@redhat.com Message-ID: <20210302110630.GD1396@bricha3-MOBL.ger.corp.intel.com> References: <2019455.957uq3bD9f@thomas> <2447657.GpPAYfsJW5@thomas> <20210302104232.GC1396@bricha3-MOBL.ger.corp.intel.com> <11617595.khkVX0lYF1@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11617595.khkVX0lYF1@thomas> Subject: Re: [dpdk-dev] telemetry logs 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 Tue, Mar 02, 2021 at 12:01:12PM +0100, Thomas Monjalon wrote: > 02/03/2021 11:42, Bruce Richardson: > > On Tue, Mar 02, 2021 at 11:23:41AM +0100, Thomas Monjalon wrote: > > > 02/03/2021 11:14, Bruce Richardson: > > > > On Mon, Mar 01, 2021 at 08:22:15PM +0100, Thomas Monjalon wrote: > > > > > Hi, > > > > > Sorry if I already asked this question. > > > > > Would it be possible to use rte_log in rte_telemetry > > > > > instead of returning telemetry_log_error at init? > > > > > > > > > It probably could be made to work by passing in the log function at init > > > > time. Haven't delved too much into the details, though. > > > > > > Actually I think a better question is about the need to init telemetry > > > if not used. It can generate an error without a need. > > > Instead of the existing option --no-telemetry, > > > what do you think of initializing the telemetry on its first use? > > > This way we could remove the dependency of EAL on telemetry? > > > > > There is no real first use - the various libraries all register their callbacks > > inside the init functions of the shared libraries. Having it initialized > > inside EAL makes things very useful, because it means that all DPDK apps > > automatically have telemetry available. > > Registering libs should be always possible, yes. > But the init of the socket can be deffered to its use, no? > Not sure what you mean here? When would you see the socket init taking place if not in EAL init? Of course, the other alternative to this problem is a solution you were previously suggesting: to move basic services such as logging to a separate library so that we split EAL into two parts, with the init being in the second higher-level part. Obviously this is a very significant amount of work though, so unlikely to be undertaken quickly.