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 A883743DD5; Tue, 9 Apr 2024 04:06:07 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 43616402B9; Tue, 9 Apr 2024 04:06:07 +0200 (CEST) Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by mails.dpdk.org (Postfix) with ESMTP id 407DE4027B for ; Tue, 9 Apr 2024 04:06:05 +0200 (CEST) Received: from mail.maildlp.com (unknown [172.19.163.48]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4VD8Ph5q2Lz1R5Ts; Tue, 9 Apr 2024 10:03:20 +0800 (CST) Received: from dggpeml500011.china.huawei.com (unknown [7.185.36.84]) by mail.maildlp.com (Postfix) with ESMTPS id 50C8B18006C; Tue, 9 Apr 2024 10:06:02 +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; Tue, 9 Apr 2024 10:06:02 +0800 Message-ID: <74224bdc-e865-4d5a-94fc-fdd6adb74558@huawei.com> Date: Tue, 9 Apr 2024 10:06:01 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] app/testpmd: handle IEEE1588 init fail Content-Language: en-US To: Ferruh Yigit , Stephen Hemminger CC: , , , David Marchand , Thomas Monjalon References: <20240330074409.273916-1-huangdengdui@huawei.com> <20240405094427.32d19496@hermes.local> From: huangdengdui In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.121.193] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) 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/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?