From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier MATZ Subject: Re: [PATCH] mk: added make target to print out system info Date: Wed, 25 Mar 2015 18:42:34 +0100 Message-ID: <5512F38A.40401@6wind.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: dev-VfR2kkLFssw@public.gmane.org To: Neil Horman Return-path: In-Reply-To: <20150325172229.GC18878-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" 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