From: Neil Horman <nhorman@tuxdriver.com>
To: dev@dpdk.org
Cc: David Marchand <david.marchand@6wind.com>,
Stephen Hemminger <stephen@networkplumber.org>,
bruce.richardson@intel.com, Panu Matilainen <pmatilai@redhat.com>,
Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: [dpdk-dev] [RFC PATCH 0/4]: Implement module information export
Date: Tue, 26 Apr 2016 13:39:47 -0400 [thread overview]
Message-ID: <1461692391-30093-1-git-send-email-nhorman@tuxdriver.com> (raw)
Hey-
So a few days ago we were reviewing Davids patch series to introduce the
abiilty to dump hardware support from pmd DSO's in a human readable format.
That effort encountered some problems, most notably the fact that stripping a
DSO removed the required information that the proposed tool keyed off, as well
as the need to dead reckon offsets between symbols that may not be constant
(dependent on architecture).
I was going to start looking into the possibility of creating a modinfo
section in a simmilar fashion to what kernel modules do in linux or BSD. I
decided to propose this solution instead though, because the kernel style
solution requires a significant amount of infrastructure that I think we can
maybe avoid maintaining, if we accept some minor caviats
To do this We emit a set of well known marker symbols for each DSO that an
external application can search for (in this case I called them
this_pmd_driver<n>, where n is a counter macro). These marker symbols are
n is a counter macro). These marker symbols are exported by PMDs for
external access. External tools can then access these symbols via the
dlopen/dlsym api (or via elfutils libraries)
The symbols above alias the rte_driver struct for each PMD, and the external
application can then interrogate the registered driver information.
I also add a pointer to the pci id table struct for each PMD so that we can
export hardware support.
This approach has a few pros and cons:
pros:
1) Its simple, and doesn't require extra infrastructure to implement. E.g. we
don't need a new tool to extract driver information and emit the C code to build
the binary data for the special section, nor do we need a custom linker script
to link said special section in place
2) Its stable. Because the marker symbols are explicitly exported, this
approach is resilient against stripping.
cons:
1) It creates an artifact in that PMD_REGISTER_DRIVER has to be used in one
compilation unit per DSO. As an example em and igb effectively merge two
drivers into one DSO, and the uses of PMD_REGISTER_DRIVER occur in two separate
C files for the same single linked DSO. Because of the use of the __COUNTER__
macro we get multiple definitions of the same marker symbols.
I would make the argument that the downside of the above artifact isn't that big
a deal. Traditionally in other projects a unit like a module (or DSO in our
case) only ever codifies a single driver (e.g. module_init() in the linux kernel
is only ever used once per built module). If we have code like igb/em that
shares some core code, we should build the shared code to object files and link
them twice, once to an em.so pmd and again to an igb.so pmd.
But regardless, I thought I would propose this to see what you all thought of
it.
FWIW, heres sample output of the pmdinfo tool from this series probing the
librte_pmd_ena.so module:
[nhorman@hmsreliant dpdk]$ ./build/app/pmdinfo
~/git/dpdk/build/lib/librte_pmd_ena.so
PMD 0 Information:
Driver Name: ena_driver
Driver Type: PCI
|====================PCI Table========================|
| VENDOR ID | DEVICE ID | SUBVENDOR ID | SUBDEVICE ID |
|-----------------------------------------------------|
| 1d0f| ec20| ffff| ffff|
| 1d0f| ec21| ffff| ffff|
|-----------------------------------------------------|
next reply other threads:[~2016-04-26 17:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-26 17:39 Neil Horman [this message]
2016-04-26 17:39 ` [dpdk-dev] [RFC PATCH 1/4] pmd: Modify PMD_REGISTER_DRIVER to emit a marker symbol Neil Horman
2016-04-26 17:39 ` [dpdk-dev] [RFC PATCH 2/4] pmds: export this_pmd_driver* symbols Neil Horman
2016-04-26 17:39 ` [dpdk-dev] [RFC PATCH 3/4] pmd: Modify drivers to export appropriate information Neil Horman
2016-04-26 17:39 ` [dpdk-dev] [RFC PATCH 4/4] pmdinfo: Add application to extract pmd driver info Neil Horman
2016-05-03 11:57 ` [dpdk-dev] [RFC PATCH 0/4]: Implement module information export Neil Horman
2016-05-04 8:24 ` David Marchand
2016-05-04 11:43 ` Neil Horman
2016-05-04 21:16 ` Thomas Monjalon
2016-05-05 9:42 ` Bruce Richardson
2016-05-05 11:38 ` Neil Horman
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=1461692391-30093-1-git-send-email-nhorman@tuxdriver.com \
--to=nhorman@tuxdriver.com \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@6wind.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).