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.ma...@oktetlabs.ru>
Signed-off-by: Ivan Malov <ivan.ma...@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <arybche...@solarflare.com>
Reviewed-by: Andy Moreton <amore...@solarflare.com>
No benefit of using rte_log_register_type_and_pick_level() here, in
"opt_loglevel_list" will be empty and this will be same as
@@ -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);
+ int ret;
+ ret = rte_log_register_type_and_pick_level(SFC_LOGTYPE_PREFIX
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
In fact it was raised during internal review and we kept as you can
Other option is to avoid usage of constructor here at all and move it
Yes, it will be tried many times, but there is no harm if it is
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.