[dpdk-dev] [PATCH] mk: added make target to print out system info

[Neil Horman]

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

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:
		<do bsd collection>
	CASE LINUX:
		<do linux collection>
	CASE OSV:
		<do osv collection>
}

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.

Neil

> Regards,
> Olivier
> 
>