From: Harish Patil <harish.patil@qlogic.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: Dept-Eng DPDK Dev <Dept-EngDPDKDev@qlogic.com>,
"Mody, Rasesh" <Rasesh.Mody@cavium.com>
Subject: Re: [dpdk-dev] [PATCH 1/7] net/qede: reduce noise in debug logs
Date: Tue, 20 Dec 2016 22:02:18 +0000 [thread overview]
Message-ID: <D47EE956.C2439%Harish.Patil@cavium.com> (raw)
In-Reply-To: <aa9e1cd8-e5a1-2d52-3e03-b2ef2b7f2360@intel.com>
>
>On 12/12/2016 5:15 PM, Harish Patil wrote:
>> Hi Ferruh,
>>
>>> On 12/3/2016 2:43 AM, Harish Patil wrote:
>>>> From: Rasesh Mody <Rasesh.Mody@cavium.com>
>>>>
>>>> Replace CONFIG_RTE_LIBRTE_QEDE_DEBUG_DRIVER with
>>>> CONFIG_RTE_LIBRTE_QEDE_DEBUG_VAL which is a 32-bit bitmapped value
>>>> where each bit represent a particular submodule to debug. Also move
>>>> notice messages under CONFIG_RTE_LIBRTE_QEDE_DEBUG_INFO.
>>>>
>>>> Signed-off-by: Harish Patil <harish.patil@qlogic.com>
>>>> Signed-off-by: Rasesh Mody <Rasesh.Mody@cavium.com>
>>>> ---
>>>> config/common_base | 2 +-
>>>> doc/guides/nics/qede.rst | 4 ++--
>>>> drivers/net/qede/qede_ethdev.c | 4 ++--
>>>> drivers/net/qede/qede_logs.h | 21 +++++----------------
>>>> 4 files changed, 10 insertions(+), 21 deletions(-)
>>>>
>>>> diff --git a/config/common_base b/config/common_base
>>>> index 4bff83a..2ffd557 100644
>>>> --- a/config/common_base
>>>> +++ b/config/common_base
>>>> @@ -320,7 +320,7 @@ CONFIG_RTE_LIBRTE_BOND_DEBUG_ALB_L1=n
>>>> CONFIG_RTE_LIBRTE_QEDE_PMD=y
>>>> CONFIG_RTE_LIBRTE_QEDE_DEBUG_INIT=n
>>>> CONFIG_RTE_LIBRTE_QEDE_DEBUG_INFO=n
>>>> -CONFIG_RTE_LIBRTE_QEDE_DEBUG_DRIVER=n
>>>> +CONFIG_RTE_LIBRTE_QEDE_DEBUG_VAL=0
>>>> CONFIG_RTE_LIBRTE_QEDE_DEBUG_TX=n
>>>> CONFIG_RTE_LIBRTE_QEDE_DEBUG_RX=n
>>>> #Provides abs path/name of the firmware file.
>>>> diff --git a/doc/guides/nics/qede.rst b/doc/guides/nics/qede.rst
>>>> index d22ecdd..ddf4248 100644
>>>> --- a/doc/guides/nics/qede.rst
>>>> +++ b/doc/guides/nics/qede.rst
>>>> @@ -103,9 +103,9 @@ enabling debugging options may affect system
>>>> performance.
>>>>
>>>> Toggle display of generic debugging messages.
>>>>
>>>> -- ``CONFIG_RTE_LIBRTE_QEDE_DEBUG_DRIVER`` (default **n**)
>>>> +- ``CONFIG_RTE_LIBRTE_QEDE_DEBUG_VAL`` (default **0**)
>>>
>>> Does it make sense to document how DEBUG_VAL used?
>>>
>>> Also commit log says bitmapped value to enable/disable a particular
>>> submodule, you may want to document here which value enable/disable
>>> which submodule.
>>>
>>>>
>>>> - Toggle display of ecore related messages.
>>>> + Control driver debug verbosity using 32-bit bitmap flags.
>>>>
>>>> - ``CONFIG_RTE_LIBRTE_QEDE_DEBUG_TX`` (default **n**)
>>>>
>>
>> Not really, I think that would be too much. But if you think it really
>> helps then perhaps yes we can document.
>> Otherwise it is just for internal debugging.
>
>As a user of your driver, how can I know how to enable / disable a
>module log?
>I know VAL enables / disables them, but I don't know what modules exists
>and what values are required.
>
>If this is just for internal debugging and user not need to configure
>this one, does it needs to be a config option in configuration file?
Okay then let me revert this change as before in v2 series. Earlier, it
was boolean config option and CONFIG_RTE_LIBRTE_QEDE_DEBUG_DRIVER=y would
enable all debug logs.
>
>>
>>
>>>
>>> <...>
>>>
>>>> diff --git a/drivers/net/qede/qede_logs.h
>>>>b/drivers/net/qede/qede_logs.h
>>>> index 45c4af0..08fdf04 100644
>>>> --- a/drivers/net/qede/qede_logs.h
>>>> +++ b/drivers/net/qede/qede_logs.h
>>>> @@ -16,15 +16,18 @@
>>>> (p_dev)->name ? (p_dev)->name : "", \
>>>> ##__VA_ARGS__)
>>>>
>>>> +#ifdef RTE_LIBRTE_QEDE_DEBUG_INFO
>>>
>>> Is "_INFO" carries any meaning in this config option, why not just
>>> RTE_LIBRTE_QEDE_DEBUG?
>>
>> INFO is used to mean just informational type of messages.
>> If you think it doesn’t make sense then I can rename it.
>
>I don't have a strong opinion, I think that _INFO is not adding value
>unless you have different config options per each level like _VERBOSE,
>_INFO, _NOTICE. But if you believe your users will benefit from it, it
>is your call.
Yes, I would like to retain INFO as it provides high-level informational
messages currently.
>
>>
>>>
>>>> #define DP_NOTICE(p_dev, is_assert, fmt, ...) \
>>>> rte_log(RTE_LOG_NOTICE, RTE_LOGTYPE_PMD,\
>>>> "[QEDE PMD: (%s)]%s:" fmt, \
>>>> (p_dev)->name ? (p_dev)->name : "", \
>>>> __func__, \
>>>> ##__VA_ARGS__)
>>>> +#else
>>>> +#define DP_NOTICE(p_dev, fmt, ...) do { } while (0)
>>>> +#endif
>>>>
>>>> #ifdef RTE_LIBRTE_QEDE_DEBUG_INFO
>>>> -
>>>> #define DP_INFO(p_dev, fmt, ...) \
>>>> rte_log(RTE_LOG_INFO, RTE_LOGTYPE_PMD, \
>>>> "[%s:%d(%s)]" fmt, \
>>>> @@ -33,10 +36,8 @@
>>>> ##__VA_ARGS__)
>>>> #else
>>>> #define DP_INFO(p_dev, fmt, ...) do { } while (0)
>>>> -
>>>> #endif
>>>>
>>>> -#ifdef RTE_LIBRTE_QEDE_DEBUG_DRIVER
>>>
>>> Are you sure you want to enable DP_VERBOSE, I guess most verbose log
>>> macro, by default? Perhaps may want to control it via
>>> RTE_LIBRTE_QEDE_DEBUG_INFO?
>>
>> DP_VERBOSE is enabled but it has a check:
>> if ((p_dev)->dp_module & module)
>> which controls what to print.
>> Here dp_module is controlled by CONFIG_RTE_LIBRTE_QEDE_DEBUG_VAL flag.
>> Hope it is clear.
>
>Clear thanks,
>
>I guess right now:
>DEBUG_VAL: enables verbose debug for selected module(s)
>DEBUG_INFO: Enables NOTICE and INFO level for ? (all modules?)
>ERR level is always enabled
>
>Again it is your call, but I think CONFIG_RTE_LIBRTE_QEDE_DEBUG can be
>used to enable/disable all debugs, and when enabled QEDE_DEBUG_VAL can
>select which modules to enable verbose debug ...
>
>>>
>>>> #define DP_VERBOSE(p_dev, module, fmt, ...) \
>>>> do { \
>>>> if ((p_dev)->dp_module & module) \
>>>> @@ -46,9 +47,7 @@
>>>> (p_dev)->name ? (p_dev)->name : "", \
>>>> ##__VA_ARGS__); \
>>>> } while (0)
>>>> -#else
>>>> -#define DP_VERBOSE(p_dev, fmt, ...) do { } while (0)
>>>> -#endif
>>>> +
>>>>
>>> <...>
>>>
>>>
>>
>
>
next prev parent reply other threads:[~2016-12-20 22:02 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-03 2:43 Harish Patil
2016-12-03 2:43 ` [dpdk-dev] [PATCH 2/7] net/qede: refactor filtering code Harish Patil
2016-12-08 16:45 ` Ferruh Yigit
2016-12-12 17:36 ` Harish Patil
2016-12-12 17:53 ` Ferruh Yigit
2016-12-20 23:12 ` Harish Patil
2016-12-03 2:43 ` [dpdk-dev] [PATCH 3/7] net/qede: add slowpath support for VXLAN tunneling Harish Patil
2016-12-03 2:43 ` [dpdk-dev] [PATCH 4/7] net/qede: add fastpath " Harish Patil
2016-12-03 2:43 ` [dpdk-dev] [PATCH 5/7] net/qede: fix RSS related issue Harish Patil
2016-12-03 2:43 ` [dpdk-dev] [PATCH 6/7] net/qede: fix maximum VF count to 0 Harish Patil
2016-12-08 16:45 ` Ferruh Yigit
2016-12-12 17:47 ` Harish Patil
2016-12-12 18:13 ` Ferruh Yigit
2016-12-19 13:38 ` Thomas Monjalon
2016-12-20 23:15 ` Harish Patil
2016-12-03 2:43 ` [dpdk-dev] [PATCH 7/7] net/qede: restrict maximum queues for PF/VF Harish Patil
2016-12-08 16:45 ` Ferruh Yigit
2016-12-12 19:29 ` Harish Patil
2016-12-12 20:10 ` Ferruh Yigit
2016-12-20 23:16 ` Harish Patil
2016-12-08 16:44 ` [dpdk-dev] [PATCH 1/7] net/qede: reduce noise in debug logs Ferruh Yigit
2016-12-12 17:15 ` Harish Patil
2016-12-12 17:50 ` Ferruh Yigit
2016-12-20 22:02 ` Harish Patil [this message]
2016-12-23 0:48 ` [dpdk-dev] [PATCH v2 " Harish Patil
2016-12-23 15:14 ` Ferruh Yigit
2016-12-23 15:25 ` Ferruh Yigit
2016-12-23 0:48 ` [dpdk-dev] [PATCH v2 2/7] net/qede: fix filtering code Harish Patil
2016-12-23 0:48 ` [dpdk-dev] [PATCH v2 3/7] net/qede: add slowpath support for VXLAN tunneling Harish Patil
2016-12-23 0:48 ` [dpdk-dev] [PATCH v2 4/7] net/qede: add fastpath " Harish Patil
2016-12-23 0:48 ` [dpdk-dev] [PATCH v2 5/7] net/qede: fix RSS related issue Harish Patil
2016-12-23 0:48 ` [dpdk-dev] [PATCH v2 6/7] net/qede: fix reporting of SR-IOV PF driver as disabled Harish Patil
2016-12-23 0:48 ` [dpdk-dev] [PATCH v2 7/7] net/qede: restrict maximum queues for PF/VF Harish Patil
2016-12-08 16:48 ` [dpdk-dev] [PATCH 1/7] net/qede: reduce noise in debug logs Ferruh Yigit
2016-12-20 23:29 ` Mody, Rasesh
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=D47EE956.C2439%Harish.Patil@cavium.com \
--to=harish.patil@qlogic.com \
--cc=Dept-EngDPDKDev@qlogic.com \
--cc=Rasesh.Mody@cavium.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.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).