From: David Marchand <david.marchand@6wind.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
Stephen Hemminger <stephen@networkplumber.org>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
Panu Matilainen <pmatilai@redhat.com>,
Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: Re: [dpdk-dev] [RFC PATCH 0/4]: Implement module information export
Date: Wed, 4 May 2016 10:24:18 +0200 [thread overview]
Message-ID: <CALwxeUth_rpL_h_NJQK6g=FoZcxw+hPL0+2SRZv7tioUHUhgGw@mail.gmail.com> (raw)
In-Reply-To: <20160503115714.GA704@hmsreliant.think-freely.org>
On Tue, May 3, 2016 at 1:57 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> On Tue, Apr 26, 2016 at 01:39:47PM -0400, Neil Horman wrote:
>> 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|
>> |-----------------------------------------------------|
>>
>>
>>
>>
> Ping, thoughts here?
- This implementation does not support binaries, so it is not suitable
for people who don't want dso, this is partially why I used bfd rather
than just dlopen.
- The name of the tool "pmdinfo" is likely to cause problems, I would
say we need to prefix t with dpdk.
- How does it behave if we strip the dsos ?
- Using __COUNTER__ seeems a bit tricky to me, can't this cause misalignments ?
- The tool output format is not script friendly from my pov.
--
David Marchand
next prev parent reply other threads:[~2016-05-04 8:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-26 17:39 Neil Horman
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 [this message]
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='CALwxeUth_rpL_h_NJQK6g=FoZcxw+hPL0+2SRZv7tioUHUhgGw@mail.gmail.com' \
--to=david.marchand@6wind.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=nhorman@tuxdriver.com \
--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).