Hi Andrew,

> -----Original Message-----
> From: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru>
> Sent: Friday, August 13, 2021 5:31 PM
> To: Xia, Chenbo <chenbo....@intel.com>; Vijay Srivastava
> <vijay.srivast...@xilinx.com>; dev@dpdk.org
> Cc: maxime.coque...@redhat.com; Vijay Kumar Srivastava <vsriv...@xilinx.com>
> Subject: Re: [PATCH 01/10] vdpa/sfc: introduce Xilinx vDPA driver
> 
> On 8/13/21 12:23 PM, Xia, Chenbo wrote:
> > Hi Andrew,
> >
> >> -----Original Message-----
> >> From: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru>
> >> Sent: Friday, August 13, 2021 4:39 PM
> >> To: Xia, Chenbo <chenbo....@intel.com>; Vijay Srivastava
> >> <vijay.srivast...@xilinx.com>; dev@dpdk.org
> >> Cc: maxime.coque...@redhat.com; Vijay Kumar Srivastava 
> >> <vsriv...@xilinx.com>
> >> Subject: Re: [PATCH 01/10] vdpa/sfc: introduce Xilinx vDPA driver
> >>
> >> Hi Chenbo,
> >>
> >> many thanks for review. See few questions/notes below.
> >>
> >> On 8/11/21 5:26 AM, Xia, Chenbo wrote:
> >>> Hi Vijay,
> >>>
> >>>> -----Original Message-----
> >>>> From: Vijay Srivastava <vijay.srivast...@xilinx.com>
> >>>> Sent: Wednesday, July 7, 2021 12:44 AM
> >>>> To: dev@dpdk.org
> >>>> Cc: maxime.coque...@redhat.com; Xia, Chenbo <chenbo....@intel.com>;
> >>>> andrew.rybche...@oktetlabs.ru; Vijay Kumar Srivastava
> <vsriv...@xilinx.com>
> >>>> Subject: [PATCH 01/10] vdpa/sfc: introduce Xilinx vDPA driver
> >>>>
> >>>> From: Vijay Kumar Srivastava <vsriv...@xilinx.com>
> >>>>
> >>>> Add new vDPA PMD to support vDPA operation by Xilinx devices.
> >>>
> >>> vDPA operations of Xilinx devices
> >>>
> >>>> This patch implements probe and remove functions.
> >>>>
> >>>> Signed-off-by: Vijay Kumar Srivastava <vsriv...@xilinx.com>
> 
> [snip]
> 
> >>>> diff --git a/drivers/vdpa/sfc/sfc_vdpa_log.h
> >> b/drivers/vdpa/sfc/sfc_vdpa_log.h
> >>>> new file mode 100644
> >>>> index 0000000..0a3d6ad
> >>>> --- /dev/null
> >>>> +++ b/drivers/vdpa/sfc/sfc_vdpa_log.h
> >>>> @@ -0,0 +1,77 @@
> >>>> +/* SPDX-License-Identifier: BSD-3-Clause
> >>>> + *
> >>>> + * Copyright(c) 2020-2021 Xilinx, Inc.
> >>>> + */
> >>>> +
> >>>> +#ifndef _SFC_VDPA_LOG_H_
> >>>> +#define _SFC_VDPA_LOG_H_
> >>>> +
> >>>> +/** Generic driver log type */
> >>>> +extern int sfc_vdpa_logtype_driver;
> >>>> +
> >>>> +/** Common log type name prefix */
> >>>> +#define SFC_VDPA_LOGTYPE_PREFIX "pmd.vdpa.sfc."
> >>>> +
> >>>> +/** Log PMD generic message, add a prefix and a line break */
> >>>> +#define SFC_VDPA_GENERIC_LOG(level, ...) \
> >>>> +        rte_log(RTE_LOG_ ## level, sfc_vdpa_logtype_driver,             
> >>>> \
> >>>> +                RTE_FMT("PMD: " RTE_FMT_HEAD(__VA_ARGS__ ,) "\n",       
> >>>> \
> >>>> +                        RTE_FMT_TAIL(__VA_ARGS__ ,)))
> >>>> +
> >>>> +/** Name prefix for the per-device log type used to report basic
> >> information
> >>>> */
> >>>> +#define SFC_VDPA_LOGTYPE_MAIN_STR       SFC_VDPA_LOGTYPE_PREFIX "main"
> >>>> +
> >>>> +#define SFC_VDPA_LOG_PREFIX_MAX 32
> >>>> +
> >>>> +/* Log PMD message, automatically add prefix and \n */
> >>>> +#define SFC_VDPA_LOG(sva, level, type, ...) \
> >>>> +        rte_log(level, type,                                    \
> >>>> +                RTE_FMT("%s" RTE_FMT_HEAD(__VA_ARGS__ ,) "\n",  \
> >>>> +                        sva->log_prefix,                        \
> >>>> +                        RTE_FMT_TAIL(__VA_ARGS__ ,)))
> >>>> +
> >>>> +#define sfc_vdpa_err(sva, ...) \
> >>>> +        do {                                                    \
> >>>> +                const struct sfc_vdpa_adapter *_sva = (sva);    \
> >>>> +                                                                \
> >>>> +                SFC_VDPA_LOG(_sva, RTE_LOG_ERR,                 \
> >>>> +                        _sva->logtype_main, __VA_ARGS__);       \
> >>>> +        } while (0)
> >>>> +
> >>>> +#define sfc_vdpa_warn(sva, ...) \
> >>>> +        do {                                                    \
> >>>> +                const struct sfc_vdpa_adapter *_sva = (sva);    \
> >>>> +                                                                \
> >>>> +                SFC_VDPA_LOG(_sva, RTE_LOG_WARNING,             \
> >>>> +                        _sva->logtype_main, __VA_ARGS__);       \
> >>>> +        } while (0)
> >>>> +
> >>>> +#define sfc_vdpa_notice(sva, ...) \
> >>>> +        do {                                                    \
> >>>> +                const struct sfc_vdpa_adapter *_sva = (sva);    \
> >>>> +                                                                \
> >>>> +                SFC_VDPA_LOG(_sva, RTE_LOG_NOTICE,              \
> >>>> +                        _sva->logtype_main, __VA_ARGS__);       \
> >>>> +        } while (0)
> >>>> +
> >>>> +#define sfc_vdpa_info(sva, ...) \
> >>>> +        do {                                                    \
> >>>> +                const struct sfc_vdpa_adapter *_sva = (sva);    \
> >>>> +                                                                \
> >>>> +                SFC_VDPA_LOG(_sva, RTE_LOG_INFO,                \
> >>>> +                        _sva->logtype_main, __VA_ARGS__);       \
> >>>> +        } while (0)
> >>>> +
> >>>
> >>> For above log, can't we make log level a parameter?
> >>> Then above four define can be one.
> >>
> >> Yes, it definitely could, but it is more convenient to have
> >> dedicated macros for different log levels and corresponding
> >> lines shorter this way.
> >
> > It could save some chars in one log line but also introduce more
> > LOC. And you may have to change every macro if things like SFC_VDPA_LOG
> > or naming of sfc_vdpa_adapter change. I prefer combining but since
> > the duplication is acceptable, I'll let you balance the pros/cons.
> 
> I see your point. I think it should be a macro sfc_vdpa_log()
> with log level and other sfc_vpda_*() macros should be just one
> liner like sfc_vdpa_log(sva, RTE_LOG_INFO, __VA_ARGS__)
> 
> Do I understand correctly that it address your concerns?

Exactly! I'd like this and you can hide RTE_LOG prefix in macro definition
, so it'll be like:

sfc_vdpa_log(sva, INFO, ...)

Thanks,
Chenbo

> 
> Andrew.
> 

Reply via email to