From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 2CE564C7F for ; Tue, 6 Mar 2018 15:56:24 +0100 (CET) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id CDA18B00067; Tue, 6 Mar 2018 14:56:22 +0000 (UTC) Received: from [192.168.38.17] (84.52.114.114) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 6 Mar 2018 14:56:18 +0000 From: Andrew Rybchenko To: Ferruh Yigit , CC: Ivan Malov References: <1516899647-8541-1-git-send-email-arybchenko@solarflare.com> <1516899647-8541-3-git-send-email-arybchenko@solarflare.com> <51bd745e-5fdd-90fe-b8c0-32f903cecf2d@intel.com> Message-ID: <8b5e125d-b04a-b992-e99a-16412f8703d3@solarflare.com> Date: Tue, 6 Mar 2018 17:56:14 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB X-Originating-IP: [84.52.114.114] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.100.1062-23702.003 X-TM-AS-Result: No--13.200700-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-MDID: 1520348183-m1TPc2r39PqL Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH 2/6] net/sfc: add support for driver-wide dynamic logging X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 14:56:24 -0000 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 >>> >>> Signed-off-by: Ivan Malov >>> Signed-off-by: Andrew Rybchenko >>> Reviewed-by: Andy Moreton >> <...> >> >>> @@ -2082,3 +2084,14 @@ RTE_PMD_REGISTER_PARAM_STRING(net_sfc_efx, >>>       SFC_KVARG_STATS_UPDATE_PERIOD_MS "= " >>>       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.