From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id 8F1F469EC for ; Fri, 17 Mar 2017 16:32:36 +0100 (CET) Received: by mail-wm0-f47.google.com with SMTP id t189so18895126wmt.1 for ; Fri, 17 Mar 2017 08:32:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=TPh13d5Plvn4ALUYqtVD8owFcLIFoEd5YaehHrnKY64=; b=ca0mciGLKYDfgHNXlb/37J1rX7iTbbPq9nXEkTK+HsSx80di95CQ3PjjR9rN0ggF3Z /kjMuLBGcvaz5NtvQX7C/gaWT79M5p74sEH/iwT4fGiXWruF4bJZEM1n7c791mwBXagx fOz1T8ycLfF+16YOtxpyThXfpU3wncGXwSp3AP64gthW5SmV7CQ8iG5XYv9xnfV6Mufo 81xp3vv/pHsTfvJLSdfLKywwtEyWvl1JAaPULQgbJMBtLW4GyqMMyattei5cmoMXy54R 0x5aR2T0oM3EEQ0XENpL6ThJ+eY/OPQ//3pbo5AWvAxLCYshP4pLDXQK1bZxlWMfl3vy CSsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=TPh13d5Plvn4ALUYqtVD8owFcLIFoEd5YaehHrnKY64=; b=WAbCG6C4wFMzgq/+ETWy7PQ8zW88jKRfOlBtQeTPZU094BI+Adv8j1v1za45EEcxRa LgVx/HODT8Ygf/aSYSZDxuwc/R68nhjENM34FRxF3d4ZSPIxKSMHPCljcSagX95qhc20 wvDj9i1SciejkWtDWDJnnzNiYGFVigmf0eW6stO+5eGihq/IOFuKMNjsJO5ctMDLhiRZ LuHS+hhfyWb1oOaWkv+wMUcJqNAegmB6wG9/cdfsj03YiYTjFb+3Qch0THHc88si8zYB k8O9EIUi608nyQ26YBHJLv2b8vB/rrL5H350edUG3eFGoInyicCNjf6+EskkclYJm9/I TxtA== X-Gm-Message-State: AFeK/H2Unt5GkpSqrwezLQoXqk+o2EjeIZ0XEO5ApIt0SZ4oDcw65msKfS0xuD0awLoaapEc X-Received: by 10.28.183.4 with SMTP id h4mr3462394wmf.32.1489764756059; Fri, 17 Mar 2017 08:32:36 -0700 (PDT) Received: from platinum (2a01cb0c03c651000226b0fffeed02fc.ipv6.abo.wanadoo.fr. [2a01:cb0c:3c6:5100:226:b0ff:feed:2fc]) by smtp.gmail.com with ESMTPSA id j26sm10289446wrb.69.2017.03.17.08.32.35 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 17 Mar 2017 08:32:35 -0700 (PDT) Date: Fri, 17 Mar 2017 16:32:33 +0100 From: Olivier Matz To: Thomas Monjalon Cc: dev@dpdk.org Message-ID: <20170317163233.082250d7@platinum> In-Reply-To: <6135132.unKH2kKz59@xps13> References: <1486387756-16865-1-git-send-email-olivier.matz@6wind.com> <6135132.unKH2kKz59@xps13> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC 0/8] eal: dynamic logs 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: Fri, 17 Mar 2017 15:32:36 -0000 Hi Thomas, On Wed, 15 Mar 2017 17:35:32 +0100, Thomas Monjalon wrote: > 2017-02-06 14:29, Olivier Matz: > > The objective of this RFC patchset is to introduce a framework to > > support dynamic log types in EAL. It also provides one example of use > > (in i40e). > > > > Features: > > - log types are identified by a string > > - at registration, a uniq identifier is associated to a log type > > - each log type can have its level changed dynamically > > - extend command line parameters to set the log level of a specific > > type, or logs matching a regular expression > > - keep compat with other legacy types (eal, malloc, ring, user*, > > etc... keep their hardcoded log type value) > > > > At the end, when, we can expect that all non-dataplane logs are moved to > > be dynamic, so we can enable/disable them at runtime, without > > recompiling. Many debug options can probably be removed from > > configuration: > > $ git grep DEBUG config/common_base | wc -l > > 89 > > I think it would be a very nice cleanup and usability improvement. > > It seems that everybody agrees that dynamic logging config is better. > There were 2 comments that I want to sum up here: > > 1/ Why not use an external log library? > > It is not obvious that there is a real benefit to use another system. > And Olivier already wrote the code for this system. > If someone writes the integration of another log system, we could > consider it. > > 2/ Why filtering by log type instead of file/function? > > File/function filtering targets DPDK debug use cases. > For application developers or system integrators, the log type seems > a good level of abstraction for logging part of the system. > Anyway, the file/function filtering could be added later if > someone integrates it in the dynamic logging configuration system. > > The conclusion is that this series seems good to integrate. > As it is a RFC, do you plan to send a refresh or can we merge it as is? I'll send a refresh, the patchset does not apply on current master. Regards, Olivier