From: Olivier MATZ <olivier.matz@6wind.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] mk: added make target to print out system info
Date: Wed, 25 Mar 2015 18:42:34 +0100 [thread overview]
Message-ID: <5512F38A.40401@6wind.com> (raw)
In-Reply-To: <20150325172229.GC18878@hmsreliant.think-freely.org>
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:
> <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.
>
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
next prev parent reply other threads:[~2015-03-25 17:42 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 [this message]
2015-03-25 17:57 ` Neil Horman
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=5512F38A.40401@6wind.com \
--to=olivier.matz@6wind.com \
--cc=dev@dpdk.org \
--cc=nhorman@tuxdriver.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).