From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) by dpdk.org (Postfix) with ESMTP id 38FA55911 for ; Mon, 6 Feb 2017 16:27:53 +0100 (CET) Received: by mail-wm0-f42.google.com with SMTP id v77so119826477wmv.0 for ; Mon, 06 Feb 2017 07:27:53 -0800 (PST) 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=/RfIr9YFeglhatxskNZZE67kVTEIAL8agxP8C1UgkY4=; b=Y/XZZBbXUkhQzFCjHA9mtnbFNg0qdDXn2zDilIXVJEsnxH6Vz7rQSQ905BEMcmJFRo tX8s7rKNfGdYlz9bCbGTVh1/DT/P01v/RV55KswWVi2aJ5nOYZ+rkirdpTKuFirPa/98 ae3zY9XBbZjFHsYpW2z5C3okqE+aSFBqYoX1qZd6ykBDTWG795rOgERV/ws5w5s2YVT3 yz7KkcYFuLI0bm7bhuUJ4cJgwEmLc9VIjnlzQUEp1JwwE0nRVkgKeXDkYtU0r5W4A+ff YBn4ruRq3YJpdcbOP1PGJyEBWWeilru64Qd8HD6uZIIDZWOy0u+PRDkfZ0JwvPTcwcM2 zYug== 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=/RfIr9YFeglhatxskNZZE67kVTEIAL8agxP8C1UgkY4=; b=NBQ8d953sRy8eJDWS4vvYzfcRphCjfx2qAF0UbCRZBYkGBdqQ1aJnTIYwIrkRP8Ye9 npsz7x7iHXkFf5u0nD3DZJ4k2PSvl9k9ziIf4ZrgWUWQv1Z9p+Gs34n/WMWQHhNMae0X obWBHeCby5CWSrn1QjllSZkEufKuQ+V6hg2k2TZluFqI9CUg5Lwxc0yP//7cHXOTcfh3 IdHM22ql7xLgcv38fWXibmhJm5M4WnxHyxmQs4S0OUhypl7MXhQAfUQCtzoW/EVwNrK7 n+GPS3RKwqZNUCdXxxbORM82pbEeiZ6/atEdtWUc752u5a/SUzbW0y/9JBL6zOmVXXmw KrIQ== X-Gm-Message-State: AMke39lB3+RDx5GkMzSJOVHH6laKvVdTk0P1ZY9cKzY+LjnIBOD++dQ9HT+9aTXExNrjFb6y X-Received: by 10.28.150.194 with SMTP id y185mr9543991wmd.47.1486394872891; Mon, 06 Feb 2017 07:27:52 -0800 (PST) Received: from platinum (2a01cb0c03c651000226b0fffeed02fc.ipv6.abo.wanadoo.fr. [2a01:cb0c:3c6:5100:226:b0ff:feed:2fc]) by smtp.gmail.com with ESMTPSA id i203sm13479836wmf.12.2017.02.06.07.27.52 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 06 Feb 2017 07:27:52 -0800 (PST) Date: Mon, 6 Feb 2017 16:27:49 +0100 From: Olivier Matz To: "Wiles, Keith" Cc: "Richardson, Bruce" , "dev@dpdk.org" , "david.marchand@6wind.com" Message-ID: <20170206162749.46bdcf22@platinum> In-Reply-To: References: <1486387756-16865-1-git-send-email-olivier.matz@6wind.com> <20170206134903.GA256940@bricha3-MOBL3.ger.corp.intel.com> <20170206151034.1ae936bc@platinum> 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=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Mon, 06 Feb 2017 15:27:53 -0000 On Mon, 6 Feb 2017 15:01:30 +0000, "Wiles, Keith" wrote: > > On Feb 6, 2017, at 8:10 AM, Olivier Matz > > wrote: > >=20 > > Hi Bruce, > >=20 > > On Mon, 6 Feb 2017 13:49:03 +0000, Bruce Richardson > > wrote: =20 > >> On Mon, Feb 06, 2017 at 02:29:08PM +0100, Olivier Matz wrote: =20 > >>> 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). > >>>=20 > >>> 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) > >>>=20 > >>> 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 > >>>=20 > >>> Comments are welcome! > >>> =20 > >> Initial scan through the patches this looks pretty good. However, > >> rather than continuing with our own logging system, have you > >> investigated what other tracing and logging systems might be out > >> there that we could possibly re-use? Could LTTng be a good fit for > >> DPDK, perhaps? =20 > >=20 > > I did not investigate much about existing logging system. I agree > > that could be a good alternative too. > >=20 > > On the other hand, I'm not really confident in adding a dependency > > to an external lib for a core component like eal. What if we deicide > > tomorrow to port dpdk to windows or any baremetal env? > >=20 > > Also, as far as I remember, the components that depend on external > > libraries are disabled today because we don't know how to properly > > manage the dependency (ex: pmd-pcap, vhost-numa, pmd-mlx, =E2=80=A6). = =20 >=20 > In a previous project I worked in we did not use log levels per say > for debugging code. We did have a couple general logging for misc > type logging. >=20 > When debugging you normally only need a couple files or functions > that need to produce logging output. In that case we defined logging > using the file and function as the key to determine if the dynamic > log messages are output. We use a string in the format of > "filename:function=E2=80=9D we allowed for a wildcard to enable all funct= ions > in a file or you can select a single function. >=20 > Using this type of logging for debugging a system is the most useful > if you just want general logging then we define something similar to > what we have today. I think the "filename:function" is not adequate if you are not the developer of that code. Example: you have a problem with a PMD, you just enable all logs for this PMD (or even all PMDs), you can check it and if you don't find the problem, you can send them on the ML for help. I think you don't care where the code is located. Regards, Olivier