From: Stephen Hemminger <stephen@networkplumber.org>
To: Alejandro Lucero <alejandro.lucero@netronome.com>
Cc: dev <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 0/5] net/nfp logging fixes
Date: Thu, 26 Apr 2018 08:42:53 -0700 [thread overview]
Message-ID: <20180426084253.1a615c82@xeon-e3> (raw)
In-Reply-To: <CAD+H992-ax+N2H4oEA7vF_FOiK7w7+X1pZ7S7PA2kt+FyCb-6g@mail.gmail.com>
On Thu, 26 Apr 2018 13:52:53 +0100
Alejandro Lucero <alejandro.lucero@netronome.com> wrote:
> Hi Stephen,
>
> Thanks for this patch set.
>
> I'm happy with it although I have some concerns regarding how the dynamic
> logs work, or maybe I have a wrong understanding about it. I have tried to
> read some doc about how it works, and I found the original patch from
> Olivier the best source, so maybe things have changed a bit and my concerns
> are unfounded.
>
> I think it is OK to specifically add something like
>
> --log-level='pmd\.i40e.*,8'
>
> if you want to debug a PMD, but if you are an user and you just want to
> know why the app is not finding any port, finding out the right string is
> not trivial. For example, with an PF, the NFP PMD goes through a process
> where the NFP device (no the NIC) is accessed first through a complex
> interface, then firmware is uploaded, DPDK ports created (for multiport
> devices), etc. I think any error in that process should be output if the
> right loglevel is there and not just if the right log type was specifically
> enabled. Is this what would happen with your patchset?
Most drivers set default log level to NOTICE. Then if they see something
obviously wrong it will show up if the right log level is used.
For the case of finding out why no drivers are found then doing
something like
--log-level='pmd.*:info'
would be useful.
Latest version makes regex optional and allows symbolic levels.
> I have suffered silent configuration problems, like the NFP card being in
> the wrong NUMA socket, and although I can solve that quickly because I have
> the knowledge, other people using NFP with DPDK require someone to help
> because they do not know what is going on. And this is usually bad because
> they have another NIC card in the same host (in the right NUMA socket) and
> the app just works smoothly then, leaving our NIC with a bad press. So I
> think, some errors should always appear with the right loglevel configured.
Driver should definitely use level > INFO for things that are wrong.
next prev parent reply other threads:[~2018-04-26 15:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-25 15:45 Stephen Hemminger
2018-04-25 15:45 ` [dpdk-dev] [PATCH 1/5] net/nfp: use correct logtype for init messages Stephen Hemminger
2018-04-25 15:45 ` [dpdk-dev] [PATCH 2/5] net/nfp: add implied new line to PMD_DRV_LOG Stephen Hemminger
2018-04-25 15:45 ` [dpdk-dev] [PATCH 3/5] net/nfp: fix double space in init log Stephen Hemminger
2018-04-25 15:45 ` [dpdk-dev] [PATCH 4/5] net/nfl: add newline in PMD_RX/TX_LOG macros Stephen Hemminger
2018-04-25 15:45 ` [dpdk-dev] [PATCH 5/5] net/nfp: use dynamic logging everywhere Stephen Hemminger
2018-04-26 12:52 ` [dpdk-dev] [PATCH 0/5] net/nfp logging fixes Alejandro Lucero
2018-04-26 15:42 ` Stephen Hemminger [this message]
2018-04-26 18:14 ` Alejandro Lucero
2018-04-26 21:52 ` 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=20180426084253.1a615c82@xeon-e3 \
--to=stephen@networkplumber.org \
--cc=alejandro.lucero@netronome.com \
--cc=dev@dpdk.org \
/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).