* [dpdk-dev] [PATCH] mk: added make target to print out system info
@ 2015-03-24 14:52 John McNamara
2015-03-24 14:52 ` John McNamara
0 siblings, 1 reply; 10+ messages in thread
From: John McNamara @ 2015-03-24 14:52 UTC (permalink / raw)
To: dev
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.
This is related to the recent call for tools brainstorming by Thomas.
http://dpdk.org/ml/archives/dev/2015-March/015499.html
Bug reports to the DPDK mailing list rarely have enough information and
require several follow-up questions to determine the version of software, the
OS, the compiler etc.
This 'make' target prints out some useful system information that can be
attached to an email. There is no guarantee that the end user will do this but
at least it can be documented and we can point them to it.
Suggestions for other useful information to be output welcome. Untested on
FreeBSD for now.
Sample output:
$ make system_info
CC version
==========
cc (GCC) 4.7.2 20121109 (Red Hat 4.7.2-8)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
DPDK version
============
2.0.0-rc2
Git commit
==========
0431d322b80858b9efa1b43480be6d4ddccf4a66
Uname
=====
Linux 3.6.10-4.fc18.x86_64 #1 SMP Tue Dec 11 18:01:27 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Hugepages
=========
AnonHugePages: 102400 kB
HugePages_Total: 1024
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
============================================================
Core and Socket Information (as reported by '/proc/cpuinfo')
============================================================
cores = [0, 1, 2, 3, 4, 5, 6, 7]
sockets = [0, 1]
Socket 0 Socket 1
-------- --------
Core 0 [0, 16] [8, 24]
Core 1 [1, 17] [9, 25]
Core 2 [2, 18] [10, 26]
Core 3 [3, 19] [11, 27]
Core 4 [4, 20] [12, 28]
Core 5 [5, 21] [13, 29]
Core 6 [6, 22] [14, 30]
Core 7 [7, 23] [15, 31]
Network devices using DPDK-compatible driver
============================================
0000:84:00.0 '82599EB 10-Gigabit SFI/SFP+ Network Connection' drv=igb_uio unused=
0000:86:00.0 '82599EB 10-Gigabit SFI/SFP+ Network Connection' drv=igb_uio unused=
Network devices using kernel driver
===================================
0000:03:00.0 'RTL8111/8168 PCI Express Gigabit Ethernet controller' if=p260p1 drv=r8169 unused=igb_uio
0000:06:00.0 'I350 Gigabit Network Connection' if=em0 drv=igb unused=igb_uio
0000:06:00.1 'I350 Gigabit Network Connection' if=eth0 drv=igb unused=igb_uio
0000:81:00.0 '82599EB 10-Gigabit SFI/SFP+ Network Connection' if=p264p1 drv=ixgbe unused=igb_uio
0000:81:00.1 '82599EB 10-Gigabit SFI/SFP+ Network Connection' if=p264p2 drv=ixgbe unused=igb_uio
0000:84:00.1 '82599EB 10-Gigabit SFI/SFP+ Network Connection' if=p263p2 drv=ixgbe unused=igb_uio
0000:86:00.1 '82599EB 10-Gigabit SFI/SFP+ Network Connection' if=p262p2 drv=ixgbe unused=igb_uio
0000:88:00.0 '82599EB 10-Gigabit SFI/SFP+ Network Connection' if=p261p1 drv=ixgbe unused=igb_uio
0000:88:00.1 '82599EB 10-Gigabit SFI/SFP+ Network Connection' if=p261p2 drv=ixgbe unused=igb_uio
Other network devices
=====================
<none>
John McNamara (1):
mk: added make target to print out system info
mk/rte.sdkroot.mk | 33 +++++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
--
1.8.1.4
^ permalink raw reply [flat|nested] 10+ messages in thread* [dpdk-dev] [PATCH] mk: added make target to print out system info 2015-03-24 14:52 [dpdk-dev] [PATCH] mk: added make target to print out system info John McNamara @ 2015-03-24 14:52 ` John McNamara 2015-03-24 17:00 ` Neil Horman 0 siblings, 1 reply; 10+ messages in thread From: John McNamara @ 2015-03-24 14:52 UTC (permalink / raw) To: dev 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-dev] [PATCH] mk: added make target to print out system info 2015-03-24 14:52 ` John McNamara @ 2015-03-24 17:00 ` Neil Horman 2015-03-25 15:06 ` Olivier MATZ 0 siblings, 1 reply; 10+ messages in thread From: Neil Horman @ 2015-03-24 17:00 UTC (permalink / raw) To: John McNamara; +Cc: dev 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. Neil ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-dev] [PATCH] mk: added make target to print out system info 2015-03-24 17:00 ` Neil Horman @ 2015-03-25 15:06 ` Olivier MATZ 2015-03-25 15:22 ` Neil Horman 0 siblings, 1 reply; 10+ messages in thread From: Olivier MATZ @ 2015-03-25 15:06 UTC (permalink / raw) To: Neil Horman, John McNamara; +Cc: dev 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. 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. Regards, Olivier ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-dev] [PATCH] mk: added make target to print out system info 2015-03-25 15:06 ` Olivier MATZ @ 2015-03-25 15:22 ` Neil Horman 2015-03-25 15:42 ` Olivier MATZ 0 siblings, 1 reply; 10+ messages in thread From: Neil Horman @ 2015-03-25 15:22 UTC (permalink / raw) To: Olivier MATZ; +Cc: dev 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. Neil > > Regards, > Olivier > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-dev] [PATCH] mk: added make target to print out system info 2015-03-25 15:22 ` Neil Horman @ 2015-03-25 15:42 ` Olivier MATZ 2015-03-25 17:22 ` Neil Horman 0 siblings, 1 reply; 10+ messages in thread From: Olivier MATZ @ 2015-03-25 15:42 UTC (permalink / raw) To: Neil Horman; +Cc: dev 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. 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. Regards, Olivier ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-dev] [PATCH] mk: added make target to print out system info 2015-03-25 15:42 ` Olivier MATZ @ 2015-03-25 17:22 ` Neil Horman 2015-03-25 17:42 ` Olivier MATZ 2015-03-25 18:11 ` Mcnamara, John 0 siblings, 2 replies; 10+ messages in thread From: Neil Horman @ 2015-03-25 17:22 UTC (permalink / raw) To: Olivier MATZ; +Cc: dev 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 > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-dev] [PATCH] mk: added make target to print out system info 2015-03-25 17:22 ` Neil Horman @ 2015-03-25 17:42 ` Olivier MATZ 2015-03-25 17:57 ` Neil Horman 2015-03-25 18:11 ` Mcnamara, John 1 sibling, 1 reply; 10+ messages in thread From: Olivier MATZ @ 2015-03-25 17:42 UTC (permalink / raw) To: Neil Horman; +Cc: 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: > <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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-dev] [PATCH] mk: added make target to print out system info 2015-03-25 17:42 ` Olivier MATZ @ 2015-03-25 17:57 ` Neil Horman 0 siblings, 0 replies; 10+ messages in thread From: Neil Horman @ 2015-03-25 17:57 UTC (permalink / raw) To: Olivier MATZ; +Cc: dev 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dpdk-dev] [PATCH] mk: added make target to print out system info 2015-03-25 17:22 ` Neil Horman 2015-03-25 17:42 ` Olivier MATZ @ 2015-03-25 18:11 ` Mcnamara, John 1 sibling, 0 replies; 10+ messages in thread From: Mcnamara, John @ 2015-03-25 18:11 UTC (permalink / raw) To: Neil Horman, Olivier MATZ; +Cc: dev > -----Original Message----- > From: Neil Horman [mailto:nhorman@tuxdriver.com] > Sent: Wednesday, March 25, 2015 5:22 PM > To: Olivier MATZ > Cc: Mcnamara, John; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH] mk: added make target to print out system > info > > > 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. > Hi Neil, I think you are probably right that documentation is the way to deal with this. I'll drop the patch and submit a checklist document with information that should be supplied when reporting bugs. It doesn't have to be added to the DPDK docs. It could be added to dpdk.org or just live in an email on the mailing list that we can point people to. The main goal is to avoid having to pull relevant information out of people over a series of emails. Perhaps it may prove not to be necessary in practice. I can add sample shell scripts for Linux/FreeBSD at the end of the doc, to cover Oliver's suggestion about consistency of reporting. Users of other OSes can add similar text if they think it is useful. John ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-03-25 18:11 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-03-24 14:52 [dpdk-dev] [PATCH] mk: added make target to print out system info 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 2015-03-25 18:11 ` Mcnamara, John
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).