From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 352EEC3A5A2 for ; Tue, 3 Sep 2019 08:06:39 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id C008E21881 for ; Tue, 3 Sep 2019 08:06:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C008E21881 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0CDEC1D40C; Tue, 3 Sep 2019 10:06:38 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 083391D168 for ; Tue, 3 Sep 2019 10:06:37 +0200 (CEST) Received: from mail-vk1-f199.google.com (mail-vk1-f199.google.com [209.85.221.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5E0E9811BF for ; Tue, 3 Sep 2019 08:06:36 +0000 (UTC) Received: by mail-vk1-f199.google.com with SMTP id m195so6921846vka.8 for ; Tue, 03 Sep 2019 01:06:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uUMmyRHAt7hfJ6PpNUHhosAAHEoEIE5oTPbVCGlHsyc=; b=UYYHBOTP/LAAeA4NhNBnEKVvBlEBBWZkO/gLpoQShOd9tH9gd0XpVHp1EsgjpEjrOS ShB2deRiTnANyZGt10Ydm0NoMjF0tYmnkIQ1vJP/p2Y/eF6QaQpNXiAPA5NmBx1S6SWl QOgoc1rvGt4w/mqM6qYIfgGMlf1ck74YtgigsAQiSdcL5Ux6H4IxzK2Ont404hfgLpxX edovtcLPhVm+p6zB3FRNMpiAIgCYiYeO6DjTuQnV6qVTxhCvry4j359KP1LPmJYmcRUZ zgnwqUM0WeQ8om/CxfOB/T+t5IVpVefN07VQ7/vdIT9Xj0AL5XUdfABD071Q+8kXPUZr 6S3Q== X-Gm-Message-State: APjAAAXbJ6/GsYIqjVNLcHLF5brhFeWst51ucvftwWhvyUN2wAdCtmhC 7rq67qm5lQlXu2C2en9HUQuV/EmgUPX/lHr99597t1Hyf1Qk/upbUdkYiBiC8RD+9+v8XTIYBnv r3KXUtyUOt51jsjV1VK0= X-Received: by 2002:a1f:bd94:: with SMTP id n142mr6118297vkf.86.1567497995590; Tue, 03 Sep 2019 01:06:35 -0700 (PDT) X-Google-Smtp-Source: APXvYqys3jOCN1fTjC8Pp5Ln8h8sg1XMdqb6etoVsh7gd424YyOY210yOzhaLT7PXeswFkqMotAYA2v1GqumwoMsgEM= X-Received: by 2002:a1f:bd94:: with SMTP id n142mr6118284vkf.86.1567497995282; Tue, 03 Sep 2019 01:06:35 -0700 (PDT) MIME-Version: 1.0 References: <1566214919-32250-1-git-send-email-david.marchand@redhat.com> <1566214919-32250-3-git-send-email-david.marchand@redhat.com> <064b2195-434d-d76f-a59c-8fad6d235f58@intel.com> In-Reply-To: <064b2195-434d-d76f-a59c-8fad6d235f58@intel.com> From: David Marchand Date: Tue, 3 Sep 2019 10:06:24 +0200 Message-ID: To: Ferruh Yigit Cc: dev Content-Type: text/plain; charset="UTF-8" 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 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 > > --- > > lib/librte_eal/common/include/rte_log.h | 12 ++++++++---- > > lib/librte_eal/rte_eal_version.map | 8 +++++++- > > 2 files changed, 15 insertions(+), 5 deletions(-) > > > > diff --git a/lib/librte_eal/common/include/rte_log.h b/lib/librte_eal/common/include/rte_log.h > > index cbb4184..c3aff00 100644 > > --- a/lib/librte_eal/common/include/rte_log.h > > +++ b/lib/librte_eal/common/include/rte_log.h > > @@ -209,9 +209,6 @@ int rte_log_cur_msg_logtype(void); > > int rte_log_register(const char *name); > > > > /** > > - * @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_log_register() is called inside. If successful, the function tries > > @@ -227,9 +224,16 @@ int rte_log_register(const char *name); > > * - >=0: the newly registered log type > > * - <0: rte_log_register() error value > > */ > > -__rte_experimental > > int rte_log_register_type_and_pick_level(const char *name, uint32_t level_def); > > +1 to remove experimental from the API. > > > > > +#define RTE_LOG_REGISTER(token, name, level, fallback) \ > > +RTE_INIT(token##_init) \ > > Does it still need to be an init time call? > Since it is dynamic now it can be during probe, even log name can be a paramter > to the "struct rte_driver" and log can be registered automatically during probe, > not sure how complex it becomes. This would not work with non driver components built as shared libraries (unless they have an explicit init symbol in the dpdk init flow). The drivers can register multiple log types so this would have to be handled. We would touch the struct rte_driver which is embedded in other objects like rte_pci_driver, breaking the abi. > > > +{ \ > > + token = rte_log_register_type_and_pick_level(name, level); \ > > + if (token < 0) \ > > The failure can be because component can try to register existing log name, or > there is no enough memory, do you think does it worth to do log, or some > additional work if component is trying to register existing log name? Yes, I can raise a warning log (using RTE_LOGTYPE_EAL type), since duplicates are not supposed to happen. > > > + token = fallback; \ > > Does the 'fallback' needs to be provided by user, it looks like everyone will > just copy/paste 'RTE_LOGTYPE_PMD' for drivers, and does it really needs to be > configurable since it is fallback. This series only touches drivers, but I expected other components would use this macro later. I can add a RTE_PMD_REGISTER_LOG macro that hides the RTE_LOGTYPE_PMD fallback value. > > Why not provide a hardcoded type for the failure case? And for that case perhaps > create a more generic logtype, something like "RTE_LOGTYPE_FALLBACK" so that it > can be as it is from all components? > I prefer to map all drivers to a logtype that means something, like RTE_LOGTYPE_PMD. Having a "fallback" could be used for all components, but this would have to be a static logtype and adding one is not possible without breaking the abi (static entries are < 32 and all values are used). -- David Marchand