From: Neil Horman <nhorman@tuxdriver.com>
To: Panu Matilainen <pmatilai@redhat.com>
Cc: dev@dpdk.org, Bruce Richardson <bruce.richardson@intel.com>,
Thomas Monjalon <thomas.monjalon@6wind.com>,
Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: [dpdk-dev] [PATCH 4/4] pmd_hw_support.py: Add tool to query binaries for hw support information
Date: Wed, 18 May 2016 08:03:00 -0400 [thread overview]
Message-ID: <20160518120300.GA29900@hmsreliant.think-freely.org> (raw)
In-Reply-To: <3ee4159d-fd29-1a20-1417-4c0a40c18779@redhat.com>
On Wed, May 18, 2016 at 02:48:30PM +0300, Panu Matilainen wrote:
> On 05/16/2016 11:41 PM, Neil Horman wrote:
> > This tool searches for the primer sting PMD_DRIVER_INFO= in any ELF binary,
> > and, if found parses the remainder of the string as a json encoded string,
> > outputting the results in either a human readable or raw, script parseable
> > format
> >
> > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> > CC: Bruce Richardson <bruce.richardson@intel.com>
> > CC: Thomas Monjalon <thomas.monjalon@6wind.com>
> > CC: Stephen Hemminger <stephen@networkplumber.org>
> > CC: Panu Matilainen <pmatilai@redhat.com>
> > ---
> > tools/pmd_hw_support.py | 174 ++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 174 insertions(+)
> > create mode 100755 tools/pmd_hw_support.py
> >
> > diff --git a/tools/pmd_hw_support.py b/tools/pmd_hw_support.py
> > new file mode 100755
> > index 0000000..0669aca
> > --- /dev/null
> > +++ b/tools/pmd_hw_support.py
> > @@ -0,0 +1,174 @@
> > +#!/usr/bin/python3
>
> I think this should use /usr/bin/python to be consistent with the other
> python scripts, and like the others work with python 2 and 3. I only tested
> it with python2 after changing this and it seemed to work fine so the
> compatibility side should be fine as-is.
>
Sure, I can change the python executable, that makes sense.
> On the whole, AFAICT the patch series does what it promises, and works for
> both static and shared linkage. Using JSON formatted strings in an ELF
> section is a sound working technical solution for the storage of the data.
> But the difference between the two cases makes me wonder about this all...
You mean the difference between checking static binaries and dynamic binaries?
yes, there is some functional difference there
>
> For static library build, you'd query the application executable, eg
Correct.
> testpmd, to get the data out. For a shared library build, that method gives
> absolutely nothing because the data is scattered around in individual
> libraries which might be just about wherever, and you need to somehow
Correct, I figured that users would be smart enough to realize that with
dynamically linked executables, they would need to look at DSO's, but I agree,
its a glaring diffrence.
> discover the location + correct library files to be able to query that. For
> the shared case, perhaps the script could be taught to walk files in
> CONFIG_RTE_EAL_PMD_PATH to give in-the-ballpark correct/identical results
My initial thought would be to run ldd on the executable, and use a heuristic to
determine relevant pmd DSO's, and then feed each of those through the python
script. I didn't want to go to that trouble unless there was consensus on it
though.
> when querying the executable as with static builds. If identical operation
> between static and shared versions is a requirement (without running the app
> in question) then query through the executable itself is practically the
> only option. Unless some kind of (auto-generated) external config file
> system ala kernel depmod / modules.dep etc is brought into the picture.
Yeah, I'm really trying to avoid that, as I think its really not a typical part
of how user space libraries are interacted with.
>
> For shared library configurations, having the data in the individual pmds is
> valuable as one could for example have rpm autogenerate provides from the
> data to ease/automate installation (in case of split packaging and/or 3rd
> party drivers). And no doubt other interesting possibilities. With static
> builds that kind of thing is not possible.
Right.
Note, this also leaves out PMD's that are loaded dynamically (i.e. via dlopen).
For those situations I don't think we have any way of 'knowing' that the
application intends to use them.
>
> Calling up on the list of requirements from
> http://dpdk.org/ml/archives/dev/2016-May/038324.html, I see a pile of
> technical requirements but perhaps we should stop for a moment to think
> about the use-cases first?
To ennumerate the list:
- query all drivers in static binary or shared library (works)
- stripping resiliency (works)
- human friendly (works)
- script friendly (works)
- show driver name (works)
- list supported device id / name (works)
- list driver options (not yet, but possible)
- show driver version if available (nope, but possible)
- show dpdk version (nope, but possible)
- show kernel dependencies (vfio/uio_pci_generic/etc) (nope)
- room for extra information? (works)
Of the items that are missing, I've already got a V2 started that can do driver
options, and is easier to expand. Adding in the the DPDK and PMD version should
be easy (though I think they can be left out, as theres currently no globaly
defined DPDK release version, its all just implicit, and driver versions aren't
really there either). I'm also hesitant to include kernel dependencies without
defining exactly what they mean (just module dependencies, or feature
enablement, or something else?). Once we define it though, adding it can be
easy.
I'll have a v2 posted soon, with the consensus corrections you have above, as
well as some other cleanups
Best
Neil
>
> To name some from the top of my head:
> - user wants to know whether the hardware on the system is supported
> - user wants to know which package(s) need to be installed to support the
> system hardware
> - user wants to list all supported hardware before going shopping
> - [what else?]
>
> ...and then think how these things would look like from the user
> perspective, in the light of the two quite dramatically differing cases of
> static vs shared linkage.
>
> P.S. Sorry for being late to this party, I'm having some health issues so my
> level of participation is a bit on-and-off at the moment.
>
> - Panu -
>
next prev parent reply other threads:[~2016-05-18 12:03 UTC|newest]
Thread overview: 166+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-16 20:41 [dpdk-dev] [PATCH 0/4] Implement pmd hardware support exports Neil Horman
2016-05-16 20:41 ` [dpdk-dev] [PATCH 1/4] pmdinfo: Add buildtools and pmdinfo utility Neil Horman
2016-05-16 20:41 ` [dpdk-dev] [PATCH 2/4] drivers: Update driver registration macro usage Neil Horman
2016-05-16 20:41 ` [dpdk-dev] [PATCH 3/4] Makefile: Do post processing on objects that register a driver Neil Horman
2016-05-16 20:41 ` [dpdk-dev] [PATCH 4/4] pmd_hw_support.py: Add tool to query binaries for hw support information Neil Horman
2016-05-18 11:48 ` Panu Matilainen
2016-05-18 12:03 ` Neil Horman [this message]
2016-05-18 12:48 ` Panu Matilainen
2016-05-18 13:48 ` Neil Horman
2016-05-19 6:08 ` Panu Matilainen
2016-05-19 13:26 ` Neil Horman
2016-05-20 7:30 ` Panu Matilainen
2016-05-20 14:06 ` Neil Horman
2016-05-23 11:56 ` Panu Matilainen
2016-05-23 13:55 ` Neil Horman
2016-05-24 6:15 ` Panu Matilainen
2016-05-24 14:55 ` Neil Horman
2016-05-18 12:38 ` Thomas Monjalon
2016-05-18 13:09 ` Panu Matilainen
2016-05-18 13:26 ` Thomas Monjalon
2016-05-18 13:54 ` Neil Horman
2016-05-18 21:08 ` [dpdk-dev] [PATCHv2 0/4] Implement pmd hardware support exports Neil Horman
2016-05-18 21:08 ` [dpdk-dev] [PATCHv2 1/4] pmdinfogen: Add buildtools and pmdinfogen utility Neil Horman
2016-05-19 7:51 ` Panu Matilainen
2016-05-19 12:00 ` Neil Horman
2016-05-18 21:08 ` [dpdk-dev] [PATCHv2 2/4] drivers: Update driver registration macro usage Neil Horman
2016-05-19 7:58 ` Panu Matilainen
2016-05-19 10:45 ` Neil Horman
2016-05-19 10:51 ` [dpdk-dev] [dpdk-dev, PATCHv2, " Jan Viktorin
[not found] ` <20160519124650.060aa09a@pcviktorin.fit.vutbr.cz>
2016-05-19 11:40 ` Neil Horman
2016-05-18 21:08 ` [dpdk-dev] [PATCHv2 3/4] Makefile: Do post processing on objects that register a driver Neil Horman
2016-05-18 21:08 ` [dpdk-dev] [PATCHv2 4/4] pmdinfo.py: Add tool to query binaries for hw and other support information Neil Horman
2016-05-19 9:02 ` Panu Matilainen
2016-05-19 12:00 ` Neil Horman
2016-05-20 5:22 ` Panu Matilainen
2016-05-20 8:55 ` Thomas Monjalon
2016-05-20 9:12 ` Panu Matilainen
2016-05-20 14:22 ` Neil Horman
2016-05-20 14:20 ` Neil Horman
2016-05-20 17:24 ` [dpdk-dev] [PATCHv3 0/5] Implement pmd hardware support exports Neil Horman
2016-05-20 17:24 ` [dpdk-dev] [PATCHv3 1/5] pmdinfogen: Add buildtools and pmdinfogen utility Neil Horman
2016-05-20 17:24 ` [dpdk-dev] [PATCHv3 2/5] drivers: Update driver registration macro usage Neil Horman
2016-05-24 6:57 ` Panu Matilainen
2016-05-24 13:21 ` Neil Horman
2016-05-20 17:24 ` [dpdk-dev] [PATCHv3 3/5] eal: Add an export symbol to expose the autoload path to external tools Neil Horman
2016-05-20 17:24 ` [dpdk-dev] [PATCHv3 4/5] Makefile: Do post processing on objects that register a driver Neil Horman
2016-05-20 17:24 ` [dpdk-dev] [PATCHv3 5/5] pmdinfo.py: Add tool to query binaries for hw and other support information Neil Horman
2016-05-24 7:41 ` Panu Matilainen
2016-05-24 15:17 ` Neil Horman
2016-05-24 8:34 ` Panu Matilainen
2016-05-24 19:41 ` [dpdk-dev] [PATCHv4 0/5] Implement pmd hardware support exports Neil Horman
2016-05-24 19:41 ` [dpdk-dev] [PATCHv4 1/5] pmdinfogen: Add buildtools and pmdinfogen utility Neil Horman
2016-05-25 13:21 ` Thomas Monjalon
2016-05-25 17:22 ` Neil Horman
2016-05-25 17:39 ` Thomas Monjalon
2016-05-25 19:13 ` Neil Horman
2016-05-25 19:39 ` Thomas Monjalon
2016-05-25 19:57 ` Neil Horman
2016-05-24 19:41 ` [dpdk-dev] [PATCHv4 2/5] drivers: Update driver registration macro usage Neil Horman
2016-05-25 16:20 ` Thomas Monjalon
2016-05-25 17:35 ` Neil Horman
2016-05-24 19:41 ` [dpdk-dev] [PATCHv4 3/5] eal: Add an export symbol to expose the autoload path to external tools Neil Horman
2016-05-24 19:41 ` [dpdk-dev] [PATCHv4 4/5] Makefile: Do post processing on objects that register a driver Neil Horman
2016-05-25 17:08 ` Thomas Monjalon
2016-05-25 17:40 ` Neil Horman
2016-05-25 18:56 ` Thomas Monjalon
2016-05-25 19:43 ` Neil Horman
2016-05-25 20:04 ` Thomas Monjalon
2016-05-25 20:16 ` Neil Horman
2016-05-24 19:41 ` [dpdk-dev] [PATCHv4 5/5] pmdinfo.py: Add tool to query binaries for hw and other support information Neil Horman
2016-05-25 17:22 ` Thomas Monjalon
2016-05-25 17:47 ` Neil Horman
2016-05-25 18:58 ` Thomas Monjalon
2016-05-27 9:16 ` Panu Matilainen
2016-05-27 11:35 ` Neil Horman
2016-05-27 12:46 ` Panu Matilainen
2016-05-25 8:32 ` [dpdk-dev] [PATCHv4 0/5] Implement pmd hardware support exports Panu Matilainen
2016-05-25 11:27 ` Neil Horman
2016-05-26 17:17 ` [dpdk-dev] [PATCHv5 0/6] " Neil Horman
2016-05-26 17:17 ` [dpdk-dev] [PATCHv5 1/6] pmdinfogen: Add buildtools and pmdinfogen utility Neil Horman
2016-05-26 17:17 ` [dpdk-dev] [PATCHv5 2/6] drivers: Update driver registration macro usage Neil Horman
2016-05-26 17:17 ` [dpdk-dev] [PATCHv5 3/6] eal: Add an export symbol to expose the autoload path to external tools Neil Horman
2016-05-26 17:17 ` [dpdk-dev] [PATCHv5 4/6] Makefile: Do post processing on objects that register a driver Neil Horman
2016-05-26 17:17 ` [dpdk-dev] [PATCHv5 5/6] pmdinfo.py: Add tool to query binaries for hw and other support information Neil Horman
2016-05-27 14:38 ` Mcnamara, John
2016-05-27 19:56 ` Neil Horman
2016-05-26 17:17 ` [dpdk-dev] [PATCHv5 6/6] remove rte.hostapp.mk Neil Horman
2016-05-31 13:57 ` [dpdk-dev] [PATCHv6 0/7] Implement pmd hardware support exports Neil Horman
2016-05-31 13:57 ` [dpdk-dev] [PATCHv6 1/7] pmdinfogen: Add buildtools and pmdinfogen utility Neil Horman
2016-06-07 9:57 ` Thomas Monjalon
2016-06-07 12:04 ` Neil Horman
2016-06-07 12:53 ` Thomas Monjalon
2016-06-07 13:03 ` Neil Horman
2016-06-07 13:24 ` Thomas Monjalon
2016-06-07 13:49 ` Neil Horman
2016-06-07 14:09 ` Thomas Monjalon
2016-05-31 13:57 ` [dpdk-dev] [PATCHv6 2/7] drivers: Update driver registration macro usage Neil Horman
2016-05-31 13:57 ` [dpdk-dev] [PATCHv6 3/7] eal: Add an export symbol to expose the autoload path to external tools Neil Horman
2016-05-31 13:57 ` [dpdk-dev] [PATCHv6 4/7] Makefile: Do post processing on objects that register a driver Neil Horman
2016-05-31 13:57 ` [dpdk-dev] [PATCHv6 5/7] pmdinfo.py: Add tool to query binaries for hw and other support information Neil Horman
2016-05-31 13:57 ` [dpdk-dev] [PATCHv6 6/7] remove rte.hostapp.mk Neil Horman
2016-05-31 13:57 ` [dpdk-dev] [PATCHv6 7/7] doc: Add prog_guide section documenting pmdinfo script Neil Horman
2016-06-08 17:14 ` Mcnamara, John
2016-06-09 17:31 ` Neil Horman
2016-06-05 0:20 ` [dpdk-dev] [PATCHv6 0/7] Implement pmd hardware support exports Neil Horman
2016-06-07 9:34 ` Thomas Monjalon
2016-06-07 12:08 ` Neil Horman
2016-06-07 12:27 ` Thomas Monjalon
2016-06-09 17:46 ` [dpdk-dev] [PATCHv7 0/6] " Neil Horman
2016-06-09 17:46 ` [dpdk-dev] [PATCHv7 1/6] pmdinfogen: Add buildtools and pmdinfogen utility Neil Horman
2016-06-16 12:29 ` Panu Matilainen
2016-06-16 13:33 ` Neil Horman
2016-06-16 14:06 ` Panu Matilainen
2016-06-16 14:41 ` Neil Horman
2016-06-09 17:46 ` [dpdk-dev] [PATCHv7 2/6] drivers: Update driver registration macro usage Neil Horman
2016-06-09 17:46 ` [dpdk-dev] [PATCHv7 3/6] eal: Add an export symbol to expose the autoload path to external tools Neil Horman
2016-06-09 17:46 ` [dpdk-dev] [PATCHv7 4/6] Makefile: Do post processing on objects that register a driver Neil Horman
2016-06-09 17:47 ` [dpdk-dev] [PATCHv7 5/6] pmdinfo.py: Add tool to query binaries for hw and other support information Neil Horman
2016-06-16 12:32 ` Panu Matilainen
2016-06-09 17:47 ` [dpdk-dev] [PATCHv7 6/6] doc: Add prog_guide section documenting pmdinfo script Neil Horman
2016-06-09 19:55 ` Mcnamara, John
2016-06-17 18:46 ` [dpdk-dev] [PATCHv8 0/6] Implement pmd hardware support exports Neil Horman
2016-06-17 18:46 ` [dpdk-dev] [PATCHv8 1/6] pmdinfogen: Add buildtools and pmdinfogen utility Neil Horman
2016-06-17 18:46 ` [dpdk-dev] [PATCHv8 2/6] drivers: Update driver registration macro usage Neil Horman
2016-07-07 11:00 ` De Lara Guarch, Pablo
2016-07-07 11:39 ` Neil Horman
2016-07-07 15:37 ` [dpdk-dev] [PATCH] crypto: normalize cryptodev pmd names with macros Neil Horman
2016-07-08 9:09 ` De Lara Guarch, Pablo
2016-07-08 12:17 ` Neil Horman
2016-07-08 12:40 ` Thomas Monjalon
2016-07-08 13:42 ` Neil Horman
2016-07-08 19:03 ` Mcnamara, John
2016-07-09 13:34 ` Neil Horman
2016-07-09 16:04 ` Mcnamara, John
2016-07-08 14:00 ` De Lara Guarch, Pablo
2016-07-08 14:14 ` Neil Horman
2016-07-08 10:03 ` Thomas Monjalon
2016-07-08 16:34 ` [dpdk-dev] [PATCH v2] " Pablo de Lara
2016-07-08 16:46 ` [dpdk-dev] [PATCH v3] " Pablo de Lara
2016-07-08 17:14 ` Thomas Monjalon
2016-06-17 18:46 ` [dpdk-dev] [PATCHv8 3/6] eal: Add an export symbol to expose the autoload path to external tools Neil Horman
2016-06-17 18:46 ` [dpdk-dev] [PATCHv8 4/6] Makefile: Do post processing on objects that register a driver Neil Horman
2016-06-17 18:46 ` [dpdk-dev] [PATCHv8 5/6] pmdinfo.py: Add tool to query binaries for hw and other support information Neil Horman
2016-06-29 15:12 ` Remy Horton
2016-06-29 16:18 ` Neil Horman
2016-06-30 7:45 ` Remy Horton
2016-06-17 18:46 ` [dpdk-dev] [PATCHv8 6/6] doc: Add prog_guide section documenting pmdinfo script Neil Horman
2016-06-29 9:18 ` [dpdk-dev] [PATCHv8 0/6] Implement pmd hardware support exports Remy Horton
2016-06-29 11:31 ` Neil Horman
2016-06-30 7:45 ` Remy Horton
2016-07-06 21:21 ` Thomas Monjalon
2016-07-04 1:13 ` [dpdk-dev] [PATCH v9 0/7] export PMD infos Thomas Monjalon
2016-07-04 1:13 ` [dpdk-dev] [PATCH v9 1/7] drivers: export infos as string symbols Thomas Monjalon
2016-07-04 1:14 ` [dpdk-dev] [PATCH v9 2/7] mk: remove recipe for tool library Thomas Monjalon
2016-07-04 1:14 ` [dpdk-dev] [PATCH v9 3/7] mk: refresh recipe for any host application Thomas Monjalon
2016-07-04 1:14 ` [dpdk-dev] [PATCH v9 4/7] pmdinfogen: parse driver to generate code to export Thomas Monjalon
2016-07-04 1:14 ` [dpdk-dev] [PATCH v9 5/7] mk: link infos generated by pmdinfogen Thomas Monjalon
2016-07-04 1:14 ` [dpdk-dev] [PATCH v9 6/7] eal: export default plugin path to external tools Thomas Monjalon
2016-07-04 1:14 ` [dpdk-dev] [PATCH v9 7/7] tools: query binaries for support information Thomas Monjalon
2016-07-04 12:34 ` [dpdk-dev] [PATCH v9 0/7] export PMD infos Neil Horman
2016-07-04 13:10 ` Thomas Monjalon
2016-07-04 16:41 ` Neil Horman
2016-07-04 20:10 ` Thomas Monjalon
2016-07-05 20:08 ` Neil Horman
2016-07-06 15:33 ` Thomas Monjalon
2016-07-04 15:22 ` Bruce Richardson
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=20160518120300.GA29900@hmsreliant.think-freely.org \
--to=nhorman@tuxdriver.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=pmatilai@redhat.com \
--cc=stephen@networkplumber.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).