From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by dpdk.org (Postfix) with ESMTP id 7DCB97EB0 for ; Wed, 25 Mar 2015 18:42:34 +0100 (CET) Received: by wibg7 with SMTP id g7so118599371wib.1 for ; Wed, 25 Mar 2015 10:42:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JmJWqWj+SceVTKTK2RsEKOx4cJcNZMUBunqv9RGtBYs=; b=hWFK0C8rzI+FbBhOp1VYEIxUKXs7rwKRAyn05Ge+uhIc5X7rrFMhuU2h9tprqskbd9 LSH82LEdT2Cu7Y0zJ6vpNwh7v1H3co6mfkX3dESOCwzQ67Nk0XD+R5wBVz20FVQ6vAHB LeLFiiwH/rRfcTooIB10QDYBj4BzE/sMGB5gTstA8HKaQb++DgwkteE/c7clnIAXbUy5 vAoKf4nAg/sLSLmYFkn4PD2fq+ZurNlyr6eTknEdVmpJmQJnZY9uk9mhJ01xbki9TqXF DKz0EcimVEfxHt9eZBLWQOKubZuh4oKaJRjkrzGyHe/kyWuetBp1ULMQpkTEVjseAsDK LbvA== X-Gm-Message-State: ALoCoQleBWzrljEY6jDPTLCLXrAI58MpnuRhzMeLix2zB+tW/52iB7XW6t/FyNH76PZBUAz0icTa X-Received: by 10.194.62.52 with SMTP id v20mr20198177wjr.137.1427305354222; Wed, 25 Mar 2015 10:42:34 -0700 (PDT) Received: from [10.16.0.195] (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id hs8sm11606289wib.11.2015.03.25.10.42.33 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Mar 2015 10:42:33 -0700 (PDT) Message-ID: <5512F38A.40401@6wind.com> Date: Wed, 25 Mar 2015 18:42:34 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 MIME-Version: 1.0 To: Neil Horman References: <1427208779-16548-1-git-send-email-john.mcnamara@intel.com> <1427208779-16548-2-git-send-email-john.mcnamara@intel.com> <20150324170058.GA13924@hmsreliant.think-freely.org> <5512CEE2.60202@6wind.com> <20150325152211.GA18878@hmsreliant.think-freely.org> <5512D75F.7020303@6wind.com> <20150325172229.GC18878@hmsreliant.think-freely.org> In-Reply-To: <20150325172229.GC18878@hmsreliant.think-freely.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] mk: added make target to print out system info X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 17:42:34 -0000 On 03/25/2015 06:22 PM, Neil Horman wrote: > On Wed, Mar 25, 2015 at 04:42:23PM +0100, Olivier MATZ wrote: >> On 03/25/2015 04:22 PM, Neil Horman wrote: >>> On Wed, Mar 25, 2015 at 04:06:10PM +0100, Olivier MATZ wrote: >>>> Hi, >>>> >>>> On 03/24/2015 06:00 PM, Neil Horman wrote: >>>>> On Tue, Mar 24, 2015 at 02:52:59PM +0000, John McNamara wrote: >>>>>> Added a 'make system_info' target to print out system info >>>>>> related to DPDK. This is intended as output that can be >>>>>> attached to bug reports. >>>>>> --- >>>>>> mk/rte.sdkroot.mk | 33 +++++++++++++++++++++++++++++++++ >>>>>> 1 file changed, 33 insertions(+) >>>>>> >>>>>> diff --git a/mk/rte.sdkroot.mk b/mk/rte.sdkroot.mk >>>>>> index e8423b0..b477d09 100644 >>>>>> --- a/mk/rte.sdkroot.mk >>>>>> +++ b/mk/rte.sdkroot.mk >>>>>> @@ -123,3 +123,36 @@ examples examples_clean: >>>>>> %: >>>>>> $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkconfig.mk checkconfig >>>>>> $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkbuild.mk $@ >>>>>> + >>>>>> +.PHONY: system_info >>>>>> +system_info: >>>>>> + $(Q)echo >>>>>> + $(Q)echo "CC version" >>>>>> + $(Q)echo "==========" >>>>>> + $(Q)$(CC) --version >>>>>> + $(Q)echo >>>>>> + >>>>>> + $(Q)echo "DPDK version" >>>>>> + $(Q)echo "============" >>>>>> + $(Q)$(MAKE) showversion >>>>>> + $(Q)echo >>>>>> + >>>>>> + $(Q)echo "Git commit" >>>>>> + $(Q)echo "==========" >>>>>> + $(Q)git log --pretty=format:'%H' -1 >>>>>> + $(Q)echo >>>>>> + >>>>>> + $(Q)echo "Uname" >>>>>> + $(Q)echo "=====" >>>>>> + $(Q)uname -srvmpio >>>>>> + $(Q)echo >>>>>> + >>>>>> + $(Q)echo "Hugepages" >>>>>> + $(Q)echo "=========" >>>>>> + $(Q)grep -i huge /proc/meminfo >>>>>> + $(Q)echo >>>>>> + >>>>>> + $(Q)tools/cpu_layout.py >>>>>> + >>>>>> + $(Q)tools/dpdk_nic_bind.py --status >>>>>> + $(Q)echo >>>>>> -- >>>>>> 1.8.1.4 >>>>>> >>>>>> >>>>> Nak, for a few reasons: >>>>> >>>>> 1) While this target is in a common makefile, at least some of the information >>>>> it gathers is operating system specfic (e.g. /proc/meminfo). This isn't going >>>>> to work on BSD, or other operating systems that we might support in the future >>>>> >>>>> 2) This is tied to the build system. Theres no guarantee that users will >>>>> diagnose problems only on the system that they built the DPDK on. >>>>> >>>>> A better solution might be to simply document the sort of information that a bug >>>>> reporter is expected to gather, along with some sample tools for doing so. >>>>> There are numerous tools to get the above information, both in isolation and in >>>>> aggregate. >>>> >>>> I agree with Neil that the Makefile is probably not the best place to >>>> put that because the target machine may not be the build machine. What >>>> about doing the same in a script? Therefore it could be embedded and >>>> executed on the target. >>>> >>> A script would be fine, as long as its cased for tools available on every OS. >>> >>>> Neil, you talk about tools that do the same kind of things. What tool >>>> are you thinking about? The problem of using external tools is that it >>>> adds a dependency with them. >>>> >>> Yes, but how is that different from the above? running cat /proc/meminfo has a >>> dependency on the existance of /proc/meminfo, which is involate on BSD. Theres >>> another file there that hold simmilar memory information, though, or perhaps a >>> memstat tool (I cant recall which). The point being, to have an appropriate bug >>> reporting tool like this, you need to determine what information you need, then >>> for each operating system you have to do the right things to get it, be that >>> read a file, run a tool, or some other operation. >> >> Agree, there's no guarantee that /proc/some/file exists on a linux >> distribution as there is no guarantee that an application is available. >> > Agreed. > >> For instance, using applications that are packaged in coreutils or >> procps should not be an issue. But I would say that using applications >> included in specific packages should be avoided, and in this case >> the /proc interface can be better. >> > Why? We just agreed that there is no guarantee that a file exists in /proc, so > its no better or worse than using an application which may or may not be > installed. If the file is available, then great, you can use it, but otherwise > you have to provide some alternate method for getting the data. Just not > collecting some of it in my mind makes such a script not worthwhile I'm just saying that on linux it is much more likely to have /proc/meminfo (which is available since at least 2.4.x kernel) instead of having a rare package providing a tool able to format /proc/meminfo. On the other hand, using a common tool is preferable if we can expect it is installed on most distributions. > All I'm saying here is that if we want to provide this functionality we need to > do one of the following: > > 1) Write a script (to remove ourselves from being bound to a build environment), > which codifies the data items we wish to collect for debugging. For each items > we need a case statement of the form: > switch $PLATFORM { > CASE BSD: > > CASE LINUX: > > CASE OSV: > > } > > Where each case either cats a file or runs an appropriate tool (making the > appropriate check for its avilability when needed). > > Or > > 2) Document the kind of data that we need when debugging, and make suggestions > in said document for what types of tools/files might provide that data, and > leaving it up to users to do the collection on their own. > > Given that we are likely to be talking about developers here, I'm inclined to go > with option 2, given that its less maintenence to keep up with. > I think providing a script is a good idea to help people to give the most common info when they report a problem. I don't think we will have a lot of maintenance cost from this script. Regards, Olivier