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