[dpdk-dev] [PATCH 2/6] net/sfc: add support for driver-wide dynamic logging
Andrew Rybchenko
arybchenko at solarflare.com
Tue Mar 6 15:56:14 CET 2018
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 at oktetlabs.ru>
>>>
>>> Signed-off-by: Ivan Malov <ivan.malov at oktetlabs.ru>
>>> Signed-off-by: Andrew Rybchenko <arybchenko at solarflare.com>
>>> Reviewed-by: Andy Moreton <amoreton at 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.
More information about the dev
mailing list