Re: [dpdk-dev] [PATCH 2/6] net/sfc: add support for driver-wide dynamic logging

[Andrew Rybchenko <arybchenko@solarflare.com>]

On 03/06/2018 05:45 PM, Andrew Rybchenko wrote:
> On 03/05/2018 05:59 PM, Ferruh Yigit wrote:
>> On 1/25/2018 5:00 PM, Andrew Rybchenko wrote:
>>> From: Ivan Malov <ivan.malov@oktetlabs.ru>
>>>
>>> Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
>>> Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
>>> Reviewed-by: Andy Moreton <amoreton@solarflare.com>
>> <...>
>>
>>> @@ -2082,3 +2084,14 @@ RTE_PMD_REGISTER_PARAM_STRING(net_sfc_efx,
>>>       SFC_KVARG_STATS_UPDATE_PERIOD_MS "=<long> "
>>>       SFC_KVARG_MCDI_LOGGING "=" SFC_KVARG_VALUES_BOOL " "
>>>       SFC_KVARG_DEBUG_INIT "=" SFC_KVARG_VALUES_BOOL);
>>> +
>>> +RTE_INIT(sfc_driver_register_logtype);
>>> +static void
>>> +sfc_driver_register_logtype(void)
>>> +{
>>> +    int ret;
>>> +
>>> +    ret = rte_log_register_type_and_pick_level(SFC_LOGTYPE_PREFIX 
>>> "driver",
>>> +                           RTE_LOG_NOTICE);
>> No benefit of using rte_log_register_type_and_pick_level() here, in 
>> this stage
>> "opt_loglevel_list" will be empty and this will be same as 
>> rte_log_register()
>
> That's true except "uniform approach is good". I.e. simply use
> rte_log_register_type_and_pick_level() everywhere to make it safe against
> code movements.
> In fact it was raised during internal review and we kept as you can 
> see it.
>
> Other option is to avoid usage of constructor here at all and move it 
> to probe.
> Yes, it will be tried many times, but there is no harm if it is 
> already registered.

In fact it could be really required if dynamic library is used and it is
pulled later using dlopen() - don't know if there are any restrictions in
DPDK which prevent it.