From: Ferruh Yigit <ferruh.yigit@amd.com>
To: huangdengdui <huangdengdui@huawei.com>,
Stephen Hemminger <stephen@networkplumber.org>
Cc: dev@dpdk.org, aman.deep.singh@intel.com, liuyonglong@huawei.com,
David Marchand <david.marchand@redhat.com>,
Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [PATCH] app/testpmd: handle IEEE1588 init fail
Date: Mon, 8 Apr 2024 09:45:51 +0100 [thread overview]
Message-ID: <a15bfb77-7ca3-4026-936a-fabcc6f030d1@amd.com> (raw)
In-Reply-To: <d8f192e2-3be8-48e1-b7d7-4db24cc41ab5@huawei.com>
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 <huangdengdui@huawei.com> 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 <huangdengdui@huawei.com>
>>
>> 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?
next prev parent reply other threads:[~2024-04-08 8:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-30 7:44 Dengdui Huang
2024-04-05 15:36 ` Singh, Aman Deep
2024-04-05 16:44 ` Stephen Hemminger
2024-04-08 5:52 ` huangdengdui
2024-04-08 8:45 ` Ferruh Yigit [this message]
2024-04-09 2:06 ` huangdengdui
2024-04-09 2:50 ` Stephen Hemminger
2024-04-17 9:26 ` huangdengdui
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a15bfb77-7ca3-4026-936a-fabcc6f030d1@amd.com \
--to=ferruh.yigit@amd.com \
--cc=aman.deep.singh@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=huangdengdui@huawei.com \
--cc=liuyonglong@huawei.com \
--cc=stephen@networkplumber.org \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).