DPDK patches and discussions
 help / color / mirror / Atom feed
From: Neil Horman <nhorman@tuxdriver.com>
To: Olivier MATZ <olivier.matz@6wind.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] mk: added make target to print out system info
Date: Wed, 25 Mar 2015 13:57:21 -0400	[thread overview]
Message-ID: <20150325175721.GD18878@hmsreliant.think-freely.org> (raw)
In-Reply-To: <5512F38A.40401@6wind.com>

On Wed, Mar 25, 2015 at 06:42:34PM +0100, Olivier MATZ wrote:
> 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.
> 
Ok, I think either I was unclear, or you misunderstood.  I'm in now way opposed
to executing /proc/meminfo when its available, Im just saying that we have to do
it in the 'linux case' of the pseudo code below.  We need to do something
different for BSD/OSV because they don't have /proc/meminfo.  They may have a
different file to read, or need a specific tool to run.

the one thing we can do is just unilaterally run cat /proc/meminfo because on
any non-linux platform, you won't get any data, which is the goal.

I'm fine with just documenting the ways to get it, or codifying it in a script,
I'm just pointing out that a script will have to be special cased for each OS
Neil

  reply	other threads:[~2015-03-25 17:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-24 14:52 John McNamara
2015-03-24 14:52 ` John McNamara
2015-03-24 17:00   ` Neil Horman
2015-03-25 15:06     ` Olivier MATZ
2015-03-25 15:22       ` Neil Horman
2015-03-25 15:42         ` Olivier MATZ
2015-03-25 17:22           ` Neil Horman
2015-03-25 17:42             ` Olivier MATZ
2015-03-25 17:57               ` Neil Horman [this message]
2015-03-25 18:11             ` Mcnamara, John

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150325175721.GD18878@hmsreliant.think-freely.org \
    --to=nhorman@tuxdriver.com \
    --cc=dev@dpdk.org \
    --cc=olivier.matz@6wind.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).