From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 466ACA0093; Fri, 22 May 2020 10:14:38 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A51041D926; Fri, 22 May 2020 10:14:37 +0200 (CEST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by dpdk.org (Postfix) with ESMTP id 4AC1A1D91D for ; Fri, 22 May 2020 10:14:35 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id CD713EC4; Fri, 22 May 2020 04:14:33 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 22 May 2020 04:14:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= PQvp24QcuAQMzN1p8nNxdkjfp+76PwQBiMA6000TiPA=; b=I23m7ZW5sjSYiL9t 9v6vT5k/g9vnEIJbm4/BivdtyfMVTICGMs7Nmw74X3dGzLMW+uW8+cLElZ9Vy6gt FAgO+PXU3q8X/G+UsRrhrxdXm4XxYG6/Sbh+iVh9zBPpvqobO+TiNnM2mlpl/wGl JdNTYfyi+vWVaZS1GdRzhQGQ0aK7nB1fYQ2q+GsnaYh7XhgUWsMrm613v74fGaqA E3hgQQc9qRLb6dZDOUpP3X50ZeXAx6j/Xal5eLbNuY9EqdsBLWByYCteju3djHDF dwi8mYb//3W4XH+055ld+8xHbwxxzceM8wA0eBUsmbUQrOajIkuF/h+w18/GztV7 aeOIsg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=PQvp24QcuAQMzN1p8nNxdkjfp+76PwQBiMA6000Ti PA=; b=s7hBj1uYEqGqP09GrX2UnpuB7SqRiPuYZdjFJ78Q1D5qhUPNyE5fP4kRL doeBT6kthNXGL3l0u38uSrQxz2katPSeeuSS2pjAOOjtA/ACdkSjBcmBs1pkMqqc 8/IoqgZitBZZvoaM9rct7g+cM6CaCjM5GmfzlFM9nywyCKp3cO84pvaqX6LANHPf tZlHHLnFT/eNnycqykH6jWjsk+S0AwS5IDPmBh4Wy8QILgOS4bGhiRPwW+97vEJN s5iDFu6XvCf3gZ8Jhn9BQb+FsIAGNdKh9r9xAlRADv7AQ+VJyoT0bXSdnRdBvGmo URCqDMBtiUmFcoGGkyq+iIUDUfFsw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddufedgtdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 356B2328005D; Fri, 22 May 2020 04:14:32 -0400 (EDT) From: Thomas Monjalon To: Jerin Kollanukkaran , "Richardson, Bruce" , "ciara.power@intel.com" Cc: David Marchand , "keith.wiles@intel.com" , dpdk-dev Date: Fri, 22 May 2020 10:14:30 +0200 Message-ID: <2135610.AARW3okAIO@thomas> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] No telemetry legacy support print X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" 22/05/2020 09:47, David Marchand: > On Fri, May 22, 2020 at 9:15 AM Jerin Kollanukkaran wrote: > > > > "No telemetry legacy support " prints pops up on all the default dpdk applications now. > > Is it worth to print? Since it using direct 'printf', we cannot even disable through dynamic logging. > > Is possible to remove that print at least, if non legacy telemetry init is successful. > > Thoughts? > > This init function is odd as it calls printf in error and warning > cases and sets an error string when it succeeds. > Let's remove the two printf in this init function. > > If we really care about the warning message, we have to initialise > *err_str to NULL (+ this must be described in the function prototype). > In EAL init, we can then add a rte_eal_init_alert with the error > string when telemetry init fails and maybe a warning message if > err_str != NULL. There are 5 printf in telemetry. The definitive fix should be to split EAL: - 1 low-level layer offering arch and OS support, including early logs. - 1 high-level layer including configuration parsing and rte_eal_init().