From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 287DFA2E1B for ; Thu, 5 Sep 2019 08:29:27 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DE79C1EB70; Thu, 5 Sep 2019 08:29:24 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id A9C551E9CF for ; Thu, 5 Sep 2019 08:29:23 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us2.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id E59A78006C; Thu, 5 Sep 2019 06:29:21 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 5 Sep 2019 07:29:14 +0100 To: Thomas Monjalon CC: Ferruh Yigit , David Marchand , , Olivier Matz References: <1566214919-32250-1-git-send-email-david.marchand@redhat.com> <2169155.oR67J0XmJ6@xps> <16cfddb8998.27dc.d74a604c1342fc6d922a87b3e5a1c1e3@solarflare.com> <4083300.tcgOVcdeWQ@xps> From: Andrew Rybchenko Message-ID: <5b3f331c-4011-63bf-3f38-44b160a6be66@solarflare.com> Date: Thu, 5 Sep 2019 09:29:10 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <4083300.tcgOVcdeWQ@xps> Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24890.003 X-TM-AS-Result: No-22.559700-8.000000-10 X-TMASE-MatchedRID: Ync95tbzDRmi6/VcDv9f0PZvT2zYoYOwC/ExpXrHizzfoEW8Nyvnb3Id eZJjQbe1GUBcLOUp4UPeVhO3jGJTymm3SnkbLZr6+CjwEqX1p7k4eGohd7gjNoxRWJphhsrcrL/ dYc9oKZXWBSRaCrpJblYF3d4K8t2ki40n6jP10twmEURBmKrZlEyQ5fRSh2654w7R7P4I0tIH1L bWLCmuiH+jR0pZfgdcqpZqVcyBRv05HWa1kxc3MWzBijri5+RVtlX8GfOXuDgz91mDYZLM5YdaY X5m6/4YJbgOoiEqV97O9GIXQI4vS9fwCYFktIJNolVO7uyOCDWIWGvfT9ZpjMK0HkBcZFjbAmdY 1rZm0EhRvU6vIuWdV4e8qU3f9IHcTCdja6CBrTcZy1iIaVWMH/fjx7YIT/BiqVMUMZkw+EIk9Qq It4u1Py/Bmhs5JI227TTcYO4wLbOcv1o9RY5FQAKDWtq/hHcNODpEoLHptXVqFv8DgDRD0QhXCo C6RIjXarXBcllfMNqa+CyzTRW9jTvPek3k5ArHSVHYMTQ1F1pUV5Q8COx3xrjOUXWmQ3OWIyccK U/Ugpt1JcIKe4igQ60Yi0eH5gfff8GN1BLVO3ZGJPF0AyfIlZJZEeH6LriByyeOkKmk553zTu35 URal5omZnwWWIBq/N862GpoHoW4sMLcUZMcjd2hQCsqhuTNiFW7LlhOHf7fDv5dDcuT2eVUu4dM bNIOZw9CeDtZbCVfdwiy/73zXOt9bqYxZO1l05BgEdUqqANR9LQinZ4QefL6qvLNjDYTwsuf7RW bvUtwEROhiiqtv8omGcq1C0C9WI/NGWt0UYPASDQuAs0pDztkLVipwmYGDePl+ROUf7eidr5N6L FIKTlncShV1VSIi X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--22.559700-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24890.003 X-MDID: 1567664963-gSQSngy9VxWD Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH 02/11] log: define logtype register wrapper for drivers 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 9/4/19 11:44 PM, Thomas Monjalon wrote: > 04/09/2019 21:58, Andrew Rybchenko: >> On September 4, 2019 22:42:12 Thomas Monjalon wrote: >> >>> 04/09/2019 21:21, Andrew Rybchenko: >>>> On 9/4/19 8:45 PM, Thomas Monjalon wrote: >>>>> 03/09/2019 10:47, Ferruh Yigit: >>>>>> On 9/3/2019 9:06 AM, David Marchand wrote: >>>>>>> On Mon, Sep 2, 2019 at 4:29 PM Ferruh Yigit 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 >>>>>>>>> --- >>>>> [...] >>>>>>>>> /** >>>>>>>>> - * @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_experimental >>>>>>>>> int rte_log_register_type_and_pick_level(const char *name, uint32_t level_def); >>>>>>>> +1 to remove experimental from the API. >>>>> I am not sure about this function API. >>>>> Why we combined register and level setting in one function? >>>> See [1] >>>> >>>> [1] http://git.dpdk.org/dpdk/commit/?id=b22e77c026 >>> Sorry, it does not explain why we mix both operations in one function. >> Exactly to have one function instead of repeating two function calls >> everywhere. Log level should be set when log type is registered. Yes, it is >> possible to factor out a function just to pick log level, but I'm not sure >> it makes sense separately. >> >> In fact may be it makes sense to substitute just register with this one >> (I.e. remove simple register from piblic API and do not highlight that >> level is picked up in function name). > Given that we use it in a macro, we could keep two separate functions > for logtype register and minimum log level (note that "minimum" is > currently a missing word in these functions). > Anyway, we will always use the single macro in our libraries. I don't understand why "minimum" is missing. It assigns level specified for the pattern if it matches, or use level_def if no match. No level comparison, last match wins. If "minimum" refers to minimum logged level, it matches rte_log_set_level() which has no "minimum" as well in neither name nor description. Moreover, EMERG is smaller than DEBUG and if we treat log levels as numbers, it sets maximum level which is logged. There are two usages right now without a macro, but it is not that important. What I'm trying to say is that rte_log_register() plus setting default after register is too error prone. It is the source of the bug which we tried to workaround introducing the function. If user sets log level (using eal command-line options), no special efforts should be required to assign it on register. So, I think register should always do it. The function name is not ideal since it is highlights details which are not really interesting. It is logging support details that log levels may be set before log types registration. if we accept DPDK-wide default, it makes level_def parameter unnecessary and the functionality to pick level may be simply moved to rte_log_register() (using helper internal function) and I see no good reasons why we really need type-specific defaults.