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 4B76643E90; Wed, 17 Apr 2024 11:26:48 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 067CF4029E; Wed, 17 Apr 2024 11:26:48 +0200 (CEST) Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by mails.dpdk.org (Postfix) with ESMTP id EBF384028B for ; Wed, 17 Apr 2024 11:26:46 +0200 (CEST) Received: from mail.maildlp.com (unknown [172.19.162.112]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4VKFrb3MGvz1HCCZ; Wed, 17 Apr 2024 17:25:51 +0800 (CST) Received: from dggpeml500011.china.huawei.com (unknown [7.185.36.84]) by mail.maildlp.com (Postfix) with ESMTPS id 246B41400DA; Wed, 17 Apr 2024 17:26:45 +0800 (CST) Received: from [10.67.121.193] (10.67.121.193) by dggpeml500011.china.huawei.com (7.185.36.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Wed, 17 Apr 2024 17:26:44 +0800 Message-ID: Date: Wed, 17 Apr 2024 17:26:44 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] app/testpmd: handle IEEE1588 init fail Content-Language: en-US To: Stephen Hemminger CC: Ferruh Yigit , , , , David Marchand , Thomas Monjalon References: <20240330074409.273916-1-huangdengdui@huawei.com> <20240405094427.32d19496@hermes.local> <74224bdc-e865-4d5a-94fc-fdd6adb74558@huawei.com> <20240408195023.5be4fed5@hermes.local> From: huangdengdui In-Reply-To: <20240408195023.5be4fed5@hermes.local> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.121.193] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To dggpeml500011.china.huawei.com (7.185.36.84) 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 On 2024/4/9 10:50, Stephen Hemminger wrote: > On Tue, 9 Apr 2024 10:06:01 +0800 > huangdengdui wrote: > >> On 2024/4/8 16:45, Ferruh Yigit wrote: >>> On 4/8/2024 6:52 AM, huangdengdui wrote: >>>> >>>> >>>> On 2024/4/6 0:44, Stephen Hemminger wrote: >>>>> On Sat, 30 Mar 2024 15:44:09 +0800 >>>>> Dengdui Huang wrote: >>>>> >>>>>> When the port's timestamping function failed to initialize >>>>>> (for example, the device does not support PTP), the packets >>>>>> received by the hardware do not contain the timestamp. >>>>>> In this case, IEEE1588 packet forwarding should not start. >>>>>> This patch fix it. >>>>>> >>>>>> Plus, adding a failure message when failed to disable PTP. >>>>>> >>>>>> Fixes: a78040c990cb ("app/testpmd: update forward engine beginning") >>>>>> Cc: stable@dpdk.org >>>>>> >>>>>> Signed-off-by: Dengdui Huang >>>>> >>>>> Noticed that ieee1588 part is printing errors to stdout, >>>>> but other parts of test-pmd are using stderr or TEST_PMD_LOG. >>>>> >>>>> It would be good to decide on one good way to handle this >>>>> across all of testpmd. >>>> >>>> Yeah, it's a bit of a mess. Is it better to use TEST_PMD_LOG? >>>> But this is a test app, and modifying it seems unnecessary. >>>> What should we do next? >>>> >>> >>> 'TESTPMD_LOG' exists and used in a few places, but still most of the >>> logging done with 'printf/fprintf'. >>> >>> Agree to have an agreement what to use, document it, and stick to it. >>> >>> >>> For some cases, like 'usage()' output (testpmd supported parameters), or >>> cmdline prompt we always want to have output, so 'printf' suits well. >>> >>> Not sure where 'TESTPMD_LOG' is needed and what is the benefit. I don't >>> remember many cases that I want to refine testpmd app level output. >>> Maybe a case can be packet verbose output, but it also has its specific >>> command to control it. >>> >>> So should we continue to 'printf/fprintf', is there any disadvantage to >>> do so? >> OK, 'printf/fprintf' is really necessary. Am I to understand it as follows? >> >> 'TESTPMD_LOG' is more suitable for printing app runtime context logs, >> such as initialization logs and uninstallation logs. >> >> 'printf' is suitable for normal interaction with the user, such as >> show port info >> >> When should we print to stderr? > > Any Unix convention is that any error message should go to stderr. > For test-pmd, using TESTPMD_LOG has benefits and problems. > The benefit is following a convention across all the startup and error > codes. And with the color log patches, errors are highlighted. > > But the current way rte_log works, the testpmd stuff ends up going > to syslog/journal which is not necessary and overly chatty. That seems hard to unify. I don't have a better idea at the moment. Do you have a better suggestion?