From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.7 required=3.0 tests=BAYES_00,DKIM_ADSP_DISCARD, DKIM_INVALID,DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1DD50C2B9F4 for ; Mon, 14 Jun 2021 16:56:51 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id 67624611CA for ; Mon, 14 Jun 2021 16:56:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 67624611CA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=oktetlabs.ru Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4196F4067E; Mon, 14 Jun 2021 18:56:49 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id F07DB4067A for ; Mon, 14 Jun 2021 18:56:47 +0200 (CEST) Received: from [192.168.1.71] (unknown [188.170.85.171]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 51C7E7F4E2; Mon, 14 Jun 2021 19:56:47 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 51C7E7F4E2 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1623689807; bh=nEQE0+rimminFh2IRc8dA2wry8ry9f9p0orWG7Ptj0c=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=N7ni+WZwdsPKw1DSDY0epVi/Ug9GKaaSgWY7HMqer/Bvbkhc1niW0zsZECRQy+QDY RBgXnJ+2DLLaAvCv/2mb/kR1hjdLw9lEnV8gFNgnpGj0s3ivxibuKOyVcg9gIEtG8C AUuisPB/xHAlZ+HBm6Jd2wc3/fJTcn8/TYMLE7T8= To: 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> From: Andrew Rybchenko Message-ID: <2876ce81-7dfc-5e02-2f4a-9861dab1f877@oktetlabs.ru> Date: Mon, 14 Jun 2021 19:56:46 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <87dd3fd0-9dab-8079-d135-50d966d6a5cd@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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/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. > 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 >>