From: Kevin Traynor <ktraynor@redhat.com>
To: Andrew Rybchenko <arybchenko@solarflare.com>,
Thomas Monjalon <thomas@monjalon.net>
Cc: dev@dpdk.org, Ferruh Yigit <ferruh.yigit@intel.com>,
Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: [dpdk-dev] [PATCH] ethdev: decrease log level for successful API
Date: Thu, 2 Aug 2018 19:27:46 +0100 [thread overview]
Message-ID: <080a3e26-121f-daf9-85f8-927d2cd6e8ba@redhat.com> (raw)
In-Reply-To: <feeb5b88-c5d3-8b26-6139-87956acf95cd@solarflare.com>
On 08/02/2018 07:01 PM, Andrew Rybchenko wrote:
> On 02.08.2018 19:14, Thomas Monjalon wrote:
>> 02/08/2018 16:52, Kevin Traynor:
>>> On 08/02/2018 03:41 PM, Andrew Rybchenko wrote:
>>>> On 02.08.2018 17:09, Kevin Traynor wrote:
>>>>> On 08/02/2018 02:52 PM, Andrew Rybchenko wrote:
>>>>>> On 02.08.2018 16:35, Kevin Traynor wrote:
>>>>>>> On 08/02/2018 01:59 PM, Andrew Rybchenko wrote:
>>>>>>>> On 02.08.2018 15:33, Kevin Traynor wrote:
>>>>>>>>> @@ -1319,5 +1319,5 @@ struct rte_eth_dev *
>>>>>>>>> if (dev->data->dev_started == 0) {
>>>>>>>>> - RTE_ETHDEV_LOG(ERR,
>>>>>>>>> + RTE_ETHDEV_LOG(DEBUG,
>>>>>>>>> "Device with port_id=%"PRIu16" already
>>>>>>>>> stopped\n",
>>>>>>>>> port_id);
>>>>>>>> I would suggest to use WARNING here. Yes, it is not an error since
>>>>>>>> nothing bad has
>>>>>>>> happened and we handle duplicate stop and duplicate start,
>>>>>>>> but I think it is bad that (buggy?) application does it. Making it
>>>>>>>> debug
>>>>>>>> we simply
>>>>>>>> hide it too much.
>>>>>>>>
>>>>>>> I think an application following the documented API is not bad or
>>>>>>> buggy.
>>>>>> I've failed to find the place were it is documented that device/queue
>>>>>> may be stopped/started twice. Could you point out?
>>>>>> Yes, return value 0 means success, but it is a separate thing.
>>>>>>
>>>>> I was commenting directly on the API and it's documentation e.g. below
>>>>> for dev start. I'm not aware of other documentation specifying how it
>>>>> can/cannot be called.
>>>> I would not say so. "0: Success. Ethernet device started" means that
>>>> function managed to do the job and finally the device is started.
>>>>
>>>> Never-mind it is not that important and already paid to much attention.
>>>> I've included in CC other ethdev maintainers (who should be there from
>>>> the very beginning). I don't mind if it is acked by other ethdev
>>>> maintainer
>>>> and applied. It is definitely not an error as it is now. Thanks.
>>>>
>>> Sure, sounds good - I'm glad we agree on something :-) I'll leave it for
>>> a day and can re-spin tomorrow.
>> I would like to give an opinion, but unfortunately it's hard to decide.
>> For sure, it should not be a WARNING level (used for non-fatal errors).
>> What else do we have? NOTICE, INFO and DEBUG.
>> I think it can be INFO.
>
> So, we have ERR (now), WARNING (my initial suggestion), NOTICE
> (by Stephen), INFO (by Thomas) and DEBUG (by Kevin) :)
>
Well, we completed the set :-)
> If it is not treated as an error in application behaviour, I agree that my
> suggestion of WARNING is not suitable. Typically NOTICE is the default
> log level and if we consider such behaviour of apps correct, it should
> be INFO to be silent by default. I really don't like DEBUG since these
> messages are still important and could be simply lost in DEBUG
> which could to be very-very verbose.
ok, I'll update and send as INFO before someone suggests adding new log
levels to choose from.
next prev parent reply other threads:[~2018-08-02 18:27 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-02 12:33 Kevin Traynor
2018-08-02 12:59 ` Andrew Rybchenko
2018-08-02 13:35 ` Kevin Traynor
2018-08-02 13:52 ` Andrew Rybchenko
2018-08-02 14:09 ` Kevin Traynor
2018-08-02 14:41 ` Andrew Rybchenko
2018-08-02 14:52 ` Kevin Traynor
2018-08-02 16:14 ` Thomas Monjalon
2018-08-02 18:01 ` Andrew Rybchenko
2018-08-02 18:27 ` Kevin Traynor [this message]
2018-08-02 12:59 ` Andrew Rybchenko
2018-08-02 15:14 ` Stephen Hemminger
2018-08-02 18:33 ` Kevin Traynor
2018-08-02 18:39 ` Kevin Traynor
2018-08-02 18:39 ` [dpdk-dev] [PATCH v2] " Kevin Traynor
2018-08-03 8:04 ` Andrew Rybchenko
2018-08-05 13:29 ` Thomas Monjalon
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=080a3e26-121f-daf9-85f8-927d2cd6e8ba@redhat.com \
--to=ktraynor@redhat.com \
--cc=arybchenko@solarflare.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.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).