On 9/3/2019 9:06 AM, David Marchand wrote:
> On Mon, Sep 2, 2019 at 4:29 PM Ferruh Yigit <ferruh.yi...@intel.com> wrote:
>>
>> On 8/19/2019 12:41 PM, David Marchand wrote:
>>> The function rte_log_register_type_and_pick_level() fills a gap for
>>> dynamically loaded code (especially drivers) who would not pick up
>>> the log level passed at startup.
>>>
>>> Let's promote it to stable and export it for use by drivers via
>>> a wrapper.
>>>
>>> Signed-off-by: David Marchand <david.march...@redhat.com>
>>> ---
>>> lib/librte_eal/common/include/rte_log.h | 12 ++++++++----
>>> lib/librte_eal/rte_eal_version.map | 8 +++++++-
>>> 2 files changed, 15 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/lib/librte_eal/common/include/rte_log.h
>>> b/lib/librte_eal/common/include/rte_log.h
>>> index cbb4184..c3aff00 100644
>>> --- a/lib/librte_eal/common/include/rte_log.h
>>> +++ b/lib/librte_eal/common/include/rte_log.h
>>> @@ -209,9 +209,6 @@ int rte_log_cur_msg_logtype(void);
>>> int rte_log_register(const char *name);
>>>
>>> /**
>>> - * @warning
>>> - * @b EXPERIMENTAL: this API may change without prior notice
>>> - *
>>> * Register a dynamic log type and try to pick its level from EAL options
>>> *
>>> * rte_log_register() is called inside. If successful, the function tries
>>> @@ -227,9 +224,16 @@ int rte_log_register(const char *name);
>>> * - >=0: the newly registered log type
>>> * - <0: rte_log_register() error value
>>> */
>>> -__rte_experimental
>>> int rte_log_register_type_and_pick_level(const char *name, uint32_t
>>> level_def);
>>
>> +1 to remove experimental from the API.
>>
>>>
>>> +#define RTE_LOG_REGISTER(token, name, level, fallback) \
>>> +RTE_INIT(token##_init) \
>>
>> Does it still need to be an init time call?
>> Since it is dynamic now it can be during probe, even log name can be a
>> paramter
>> to the "struct rte_driver" and log can be registered automatically during
>> probe,
>> not sure how complex it becomes.
>
> This would not work with non driver components built as shared
> libraries (unless they have an explicit init symbol in the dpdk init
> flow).
Right.
>
> The drivers can register multiple log types so this would have to be handled.
> We would touch the struct rte_driver which is embedded in other
> objects like rte_pci_driver, breaking the abi.
Yes they may require multiple logs, +abi break, so forget about it.
>
>
>>
>>> +{ \
>>> + token = rte_log_register_type_and_pick_level(name, level); \
>>> + if (token < 0) \
>>
>> The failure can be because component can try to register existing log name,
>> or
>> there is no enough memory, do you think does it worth to do log, or some
>> additional work if component is trying to register existing log name?
>
> Yes, I can raise a warning log (using RTE_LOGTYPE_EAL type), since
> duplicates are not supposed to happen.
I was checking if we can detect the error from duplication, there can be a
defect it that logic:
Call trace is:
rte_log_register_type_and_pick_level
type = rte_log_register(name);
id = rte_log_lookup(name);
if (id >= 0)
return id
if (type < 0)
return type
"type > 0" for the duplication case but error check only checks if "type < 0"
>
>
>>
>>> + token = fallback; \
>>
>> Does the 'fallback' needs to be provided by user, it looks like everyone will
>> just copy/paste 'RTE_LOGTYPE_PMD' for drivers, and does it really needs to be
>> configurable since it is fallback.
>
> This series only touches drivers, but I expected other components
> would use this macro later.
> I can add a RTE_PMD_REGISTER_LOG macro that hides the RTE_LOGTYPE_PMD
> fallback value.
>
>
>>
>> Why not provide a hardcoded type for the failure case? And for that case
>> perhaps
>> create a more generic logtype, something like "RTE_LOGTYPE_FALLBACK" so that
>> it
>> can be as it is from all components?
>>
>
> I prefer to map all drivers to a logtype that means something, like
> RTE_LOGTYPE_PMD.
In that manner it make sense agreed, but previously drivers were using
'RTE_LOGTYPE_PMD' instead of having their own log types, Stephen did some work
to replace the 'RTE_LOGTYPE_PMD' so that it can be deprecated,
starting to use it again as fallback may lead drivers using it again as log type
in their drivers, may they wouldn't but this is what I concern. Something with
name 'RTE_LOGTYPE_FALLBACK' clear to not use as default logtype in drivers.
>
> Having a "fallback" could be used for all components, but this would
> have to be a static logtype and adding one is not possible without
> breaking the abi (static entries are < 32 and all values are used).
There is a gap between 'RTE_LOGTYPE_GSO' & 'RTE_LOGTYPE_USER1' ...
>
>
> --
> David Marchand
>
