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 795C8A051C; Fri, 26 Jun 2020 13:43:08 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 516B01BED9; Fri, 26 Jun 2020 13:43:07 +0200 (CEST) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) by dpdk.org (Postfix) with ESMTP id 7B6A51BED5 for ; Fri, 26 Jun 2020 13:43:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1593171784; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=m7j9dgFNsVbvivhSqmGYaCWDY78+2YY6Q561ISQGuc4=; b=A+IstH+IOb6PYJipsK9+C+CXhSFmXtQCCXenRndy3M63qpNisGNxZcaPSVLRIDLvT7zQnc bBYXK+6ogF7mPXP5QijBy2kCfCKkC1uxlEJjOAAGA4tHslqiBXuMM159+TMPl3sQlbmS+N qzP5pWys7crDNgzoFxK/ld1z5dpaGN4= Received: from mail-ua1-f71.google.com (mail-ua1-f71.google.com [209.85.222.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-37-lVAJz859PQSkqn96dGWHpQ-1; Fri, 26 Jun 2020 07:43:03 -0400 X-MC-Unique: lVAJz859PQSkqn96dGWHpQ-1 Received: by mail-ua1-f71.google.com with SMTP id l12so1571518uap.23 for ; Fri, 26 Jun 2020 04:43:03 -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=m7j9dgFNsVbvivhSqmGYaCWDY78+2YY6Q561ISQGuc4=; b=jgX4aqwe5ale+slmziNFjCb9uIKuH6W3sUFp6P+eyC6MTgCgEWCMvBJzdkatAQoSL5 5kxEVg4ieE/QJzK5GJCvbpOo5dy7VWbDmciSeKJkuXwr3YATEaVc3JtSo4H+1FYrUcuH /wZWOmcyh04OvVal276wEBoFSU2ybITbMuGhoY0DfeILInG9ZxFeXTl42YYIzYlbvw8f Yf2pPK/5GWeiJdZAZUJTXUrImtZBZz+kiatQwC8ag5i1cf6RoFpLYMsBoOASzaT5dVpJ +cCz+pnzGdhlZA7wZ2kaOPSSxVY4y2CSsOvf0oBKzn1akL61DpiGm5IWDrA5RE18nJJA EkNA== X-Gm-Message-State: AOAM530Uoh+2V9LdpOV5Nmb2enVCTssVfjZdAd9s3WNLrynnzhonKqIn x6Wm6WGPcgDJcjCfoOINmuHhWMV4mzj8LL2f4niJNDA1CQdK9yYowDuDAxJjIOuG8fWVJgwrmK0 zZLaCRgAPCIiuf130yQs= X-Received: by 2002:a1f:255:: with SMTP id 82mr1687686vkc.39.1593171782848; Fri, 26 Jun 2020 04:43:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxEo53EKkuRCqRD0IIIzXpKElY1NNpLSffswPy5bPnC0WYo/CXKQBE7RGIaA35Dv0GcEuF7eNap2fNSW4T3TZc= X-Received: by 2002:a1f:255:: with SMTP id 82mr1687669vkc.39.1593171782504; Fri, 26 Jun 2020 04:43:02 -0700 (PDT) MIME-Version: 1.0 References: <20200617063047.1555518-1-jerinj@marvell.com> <20200617063047.1555518-2-jerinj@marvell.com> <4becf100-7f0f-d051-a40c-3944e101381a@solarflare.com> <11e13bf9-8400-50de-4638-cdd1286915e4@solarflare.com> In-Reply-To: From: David Marchand Date: Fri, 26 Jun 2020 13:42:51 +0200 Message-ID: To: Jerin Jacob Cc: Andrew Rybchenko , Jerin Jacob Kollanukkaran , dev , Thomas Monjalon , Olivier Matz Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH 01/13] eal/log: introduce log register macro 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 Fri, Jun 26, 2020 at 1:16 PM Jerin Jacob wrote: > > > Alternative is to keep variable declaration outside, > > > as David suggested, and I tend to agree that it is a > > > bit better. Macro name says 'register'. It is not > > > 'declare and register'. Also it avoids static-vs-extern > > > problem completely. The solution allows to keep the > > > variable declaration untouched and put constructor (macro) > > > at the end of fine where constructors typically reside. > > > > My only concern with that approach is that, We can not save a lot of > > code duplication > > with that scheme. ie. it is [1] vs [2]. We can change the MACRO name > > accordingly if that is a concern. Any suggestions? > > > > Let me know your preference on [1] vs [2], I will stick with for the > > next version. > > If there are no other comments, I change RTE_LOG_REGISTER to static version > and RTE_LOG_REGISTER_EXTERN for a non-static version and send the next version. - Having a macro that does more than what its name tells is inconvenient. The trace framework differentiates declaration and registration. Why merge things in the log framework? Saving one line is not worth it. - Having components set log levels at init time in the macro is a bug to me. This has been worked around with rte_log_register/rte_log_register_and_pick_level but the initial problem is that rte_log_set_level* should only be called by the user. There should be a default level for all dpdk components (which means a common interpretation of each level), then the user chooses which logs he wants to see. At the moment, let's say I am looking at a live system, by default, we have: id 0: lib.eal, level is info id 1: lib.malloc, level is info id 2: lib.ring, level is info id 3: lib.mempool, level is info id 4: lib.timer, level is info id 5: pmd, level is info ... id 32: lib.bbdev, level is notice id 33: lib.bpf, level is info id 34: bus.dpaa, level is notice id 35: bus.fslmc, level is notice id 36: bus.ifpga, level is notice id 37: bus.vdev, level is notice id 38: bus.vmbus, level is notice id 39: lib.cfgfile, level is info id 40: pmd.common.dpaax, level is error ... I enable the logs for a component, set it to debug, I get my logs. If now I want to reset the logs to the initial state, err... well unless I took note of it, I don't know what the default level is. But I should not have to care. Restarting dpdk sure is something you can do with testpmd but not with real systems. -- David Marchand