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 C3C3BA0C45; Mon, 14 Jun 2021 19:49:39 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 43B774067E; Mon, 14 Jun 2021 19:49:39 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by mails.dpdk.org (Postfix) with ESMTP id B84714067A for ; Mon, 14 Jun 2021 19:49:36 +0200 (CEST) IronPort-SDR: P1LlIJIKemPOGWxXoiFCaNw1mOE70uepsyxz6DEKJYbh1onmTI05wdkjoP3RKiZZRKa9A/wJy1 UA6025aD1PNA== X-IronPort-AV: E=McAfee;i="6200,9189,10015"; a="185545434" X-IronPort-AV: E=Sophos;i="5.83,273,1616482800"; d="scan'208,217";a="185545434" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jun 2021 10:49:35 -0700 IronPort-SDR: qH1cgk1FkPnrINflQJFHD9IRsta7/4jrfJfSRMOEJeARQYXb3ii5Eddf6ZKwuLiv5+H8GLaODG 8LCcfJb06ZNA== X-IronPort-AV: E=Sophos;i="5.83,273,1616482800"; d="scan'208,217";a="420851033" Received: from amandee1-mobl.gar.corp.intel.com (HELO [10.213.82.203]) ([10.213.82.203]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jun 2021 10:49:32 -0700 To: Andrew Rybchenko , Ferruh Yigit , "Li, Xiaoyun" Cc: "dev@dpdk.org" , Bruce Richardson References: <20210527162452.1568351-1-andrew.rybchenko@oktetlabs.ru> <1f419fbb-b951-1a84-3329-97701c32c956@oktetlabs.ru> <87dd3fd0-9dab-8079-d135-50d966d6a5cd@intel.com> <2876ce81-7dfc-5e02-2f4a-9861dab1f877@oktetlabs.ru> From: "Singh, Aman Deep" Message-ID: Date: Mon, 14 Jun 2021 23:19:28 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: <2876ce81-7dfc-5e02-2f4a-9861dab1f877@oktetlabs.ru> Content-Language: en-GB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [dpdk-dev] [PATCH] app/testpmd: send failure logs to stderr 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 6/14/2021 10:26 PM, Andrew Rybchenko wrote: > On 6/11/21 1:35 PM, Ferruh Yigit wrote: >> On 6/11/2021 10:19 AM, Andrew Rybchenko wrote: >>> On 6/11/21 5:06 AM, Li, Xiaoyun wrote: >>>> Hi >>>> -----Original Message----- >>>> From: Andrew Rybchenko >>>> Sent: Friday, May 28, 2021 00:25 >>>> To: Li, Xiaoyun >>>> Cc: dev@dpdk.org >>>> Subject: [PATCH] app/testpmd: send failure logs to stderr >>>> >>>> Running with stdout suppressed or redirected for further processing >>>> is very confusing in the case of errors. >>>> >>>> Signed-off-by: Andrew Rybchenko >>>> --- >>>> >>>> This patch looks good to me. >>>> But what do you think about make it as a fix and backport to stable >>>> branches? >>>> Anyway works for me. >>> >>> I have no strong opinion on the topic. >>> >>> @Ferruh, what do you think? >>> >> >> Same here, no strong opinion. >> Sending errors to 'stderr' looks correct thing to do, but changing >> behavior in >> the LTS may cause some unexpected side affect, if it is scripted and >> testpmd >> output is parsed etc... For this possibility I would wait for the >> next LTS. > > So, I guess all agree that backporting to LTS is a bad idea because of > behaviour change. > > As I said in a sub-thread I tend to apply in v21.08 since it is a right > thing to do like a fix, but the fix is not that required to be > backported to change behaviour of LTS releases. > >> And because of same reason perhaps a release note can be added. > > I'll make v2 with release notes added. Good point. > >> Also there is 'TESTPMD_LOG' macro for logs in testpmd, (as well as >> 'RTE_LOG' >> macro), I don't know if we should switch all logs, including >> 'printf', to >> 'TESTPMD_LOG' macro? >> Later stdout/sderr can be managed in rte_log level, instead of any >> specific >> logic for the testpmd. > > I think fprintf() is a better option for debug tool, since its > messages should not go to syslog etc. It should go to stdout/stderr > regardless of logging configuration and log level settings. For loging, currently we are using multiple API's in testpmd (TESTPMD_LOG, RTE_LOG,  snprintf, printf). I agree with Ferruh, in long run we should use single loging mechanism where log_level should decide the output stream. For now fprintf() seems OK, as we can pass the output stream compared to printf(). > >> Even there was a defect for this in the rte_log level, that logs >> should go to >> stderr: https://bugs.dpdk.org/show_bug.cgi?id=8 >> >> >>>> Acked-by: Xiaoyun Li >>> > Acked-by: Aman Deep Singh