Re: [dpdk-dev] [PATCH 01/10] vdpa/sfc: introduce Xilinx vDPA driver

[Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>]

On 8/13/21 12:23 PM, Xia, Chenbo wrote:
> Hi Andrew,
> 
>> -----Original Message-----
>> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>> Sent: Friday, August 13, 2021 4:39 PM
>> To: Xia, Chenbo <chenbo.xia@intel.com>; Vijay Srivastava
>> <vijay.srivastava@xilinx.com>; dev@dpdk.org
>> Cc: maxime.coquelin@redhat.com; Vijay Kumar Srivastava <vsrivast@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.srivastava@xilinx.com>
>>>> Sent: Wednesday, July 7, 2021 12:44 AM
>>>> To: dev@dpdk.org
>>>> Cc: maxime.coquelin@redhat.com; Xia, Chenbo <chenbo.xia@intel.com>;
>>>> andrew.rybchenko@oktetlabs.ru; Vijay Kumar Srivastava <vsrivast@xilinx.com>
>>>> Subject: [PATCH 01/10] vdpa/sfc: introduce Xilinx vDPA driver
>>>>
>>>> From: Vijay Kumar Srivastava <vsrivast@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 <vsrivast@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?

Andrew.