From: "Wiles, Keith" <keith.wiles@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC PATCH] tools:new tool for system info CPU, memory and huge pages
Date: Mon, 16 May 2016 14:38:20 +0000 [thread overview]
Message-ID: <954C2793-6A54-44CB-9356-32C4E663316D@intel.com> (raw)
In-Reply-To: <3913390.TQD3aJPodK@xps13>
>2016-05-16 14:11, Wiles, Keith:
>> >2016-05-13 15:48, Wiles, Keith:
>> >> I create this new tool to combine some information and use /sys/devices instead. What I was hoping was some of you could try this script and see if it works correctly. Also I was hope to find out if this script is useful and what other features you would like in this type of tool.
>> >
>> >What is the intent of this script? Is it to be used for bug report?
>> >There already have some tools to display system informations. Why adding
>> >one more?
>> >Examples of useful tools: hwloc/lstopo, lspci, hugeadm.
>>
>> I was looking to replace the cpu_layout.py tool which uses the /procfs instead of /sysfs, just figured we could then add some extra information into this script as well. Yes, we have other tools, but some people do not know or use or install these tools. I was hoping this one would be able to display a number of things to help the developer and us in helping them debug problems.
>>
>> Stephen Hemminger sent an email about the use of sysfs instead of procfs.
>> http://dpdk.org/ml/archives/dev/2016-May/038560.html
>
>I agree that cpu_layout.py should be removed.
>Should we implement something else? Or just point to existing tools?
Well I did create something else :-) As for pointing to existing tools, we should do that anyway in the documentation.
>Or call existing tools from a small script?
Calling the existing tools could be a problem as they may not be installed, but they could install the tools too after the script points it out.
>Is it the DPDK focus to develop and maintain such tool?
I can not answer that question per say. I can at least be the maintainer for this script or someone else.
I think we need something that pulls all of the information from the system for the developer to see at a quick glance to help debug his system. Also we can then say run this script and post to the list, which is nice and simple as a debug aid.
>
Regards,
Keith
next prev parent reply other threads:[~2016-05-16 14:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-13 15:48 Wiles, Keith
2016-05-16 9:32 ` Thomas Monjalon
2016-05-16 14:11 ` Wiles, Keith
2016-05-16 14:31 ` Thomas Monjalon
2016-05-16 14:38 ` Wiles, Keith [this message]
2016-05-16 15:14 ` Richardson, Bruce
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=954C2793-6A54-44CB-9356-32C4E663316D@intel.com \
--to=keith.wiles@intel.com \
--cc=dev@dpdk.org \
--cc=thomas.monjalon@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).