From: Thomas Monjalon <thomas@monjalon.net>
To: "Wiles, Keith" <keith.wiles@intel.com>
Cc: Nithin Kumar Dabilpuram <ndabilpuram@marvell.com>,
"Yigit, Ferruh" <ferruh.yigit@intel.com>,
Andrew Rybchenko <arybchenko@solarflare.com>,
"dev@dpdk.org" <dev@dpdk.org>,
Jerin Jacob Kollanukkaran <jerinj@marvell.com>
Subject: Re: [dpdk-dev] [PATCH v2] ethdev: report error on name truncation
Date: Sun, 13 Jan 2019 22:21:08 +0100 [thread overview]
Message-ID: <7520504.p0jQqc19KO@xps> (raw)
In-Reply-To: <17CD35BA-B70C-4F7C-A90B-636BB02148C8@intel.com>
13/01/2019 21:19, Wiles, Keith:
> > On Jan 13, 2019, at 2:02 PM, Thomas Monjalon <thomas@monjalon.net> wrote:
> > 13/01/2019 20:28, Wiles, Keith:
> >>> On Jan 13, 2019, at 9:38 AM, Nithin Kumar Dabilpuram <ndabilpuram@marvell.com> wrote:
> >>> --- a/lib/librte_ethdev/rte_ethdev.c
> >>> +++ b/lib/librte_ethdev/rte_ethdev.c
> >>> + if (rc >= RTE_MEMZONE_NAMESIZE) {
> >>> + RTE_ETHDEV_LOG(ERR, "truncated name");
> >>> + rte_errno = ENAMETOOLONG;
> >>> + return NULL;
> >>> + }
> >>
> >> I we are already returning an error here should the RTE_LOG be DEBUG
> >> and not ERR.
> >> Of course this does mean we would have to check return codes :-)
> >
> > In the general case, we should always log the errors as RTE_LOG_ERR,
> > no matter it is handled and logged again at an upper level.
> > Don't you think so?
>
> My only concern is cluttering up the console output and developers should be checking return codes, which I know we do not do sometimes in DPDK.
> I think we need to do some cleaning up of DPDK and test return codes or make the function return void, but that is a different problem then this one.
>
> If we are fine with this type of log style then we can leave it. To me is just seem redundant if we are returning a code the calling function should report the error. In some cases we will get two or more messages about the same problem depending on the call path.
The log can be different at different levels.
The deepest log will give details, while other logs will give context.
The more error logs we have, the better it may be for the user.
I understand the concern about keeping logs clean, but for errors,
I don't see possible redundancy as a spam.
Anyone else think differently?
next prev parent reply other threads:[~2019-01-13 21:21 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-07 14:40 [dpdk-dev] [PATCH] " Nithin Kumar Dabilpuram
2019-01-07 14:47 ` Andrew Rybchenko
2019-01-07 15:53 ` Stephen Hemminger
2019-01-07 16:17 ` Andrew Rybchenko
2019-01-08 6:06 ` [dpdk-dev] [EXT] " Nithin Kumar Dabilpuram
2019-01-07 14:50 ` [dpdk-dev] " Thomas Monjalon
2019-01-08 5:32 ` [dpdk-dev] [EXT] " Nithin Kumar Dabilpuram
2019-01-13 15:38 ` [dpdk-dev] [PATCH v2] " Nithin Kumar Dabilpuram
2019-01-13 19:28 ` Wiles, Keith
2019-01-13 20:02 ` Thomas Monjalon
2019-01-13 20:19 ` Wiles, Keith
2019-01-13 21:21 ` Thomas Monjalon [this message]
2019-01-14 7:32 ` Andrew Rybchenko
2019-01-14 14:30 ` Thomas Monjalon
2019-01-17 14:13 ` [dpdk-dev] [PATCH v3] " Nithin Kumar Dabilpuram
2019-01-17 15:38 ` Thomas Monjalon
2019-01-17 17:07 ` Ferruh Yigit
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=7520504.p0jQqc19KO@xps \
--to=thomas@monjalon.net \
--cc=arybchenko@solarflare.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=jerinj@marvell.com \
--cc=keith.wiles@intel.com \
--cc=ndabilpuram@marvell.com \
/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).