[dpdk-dev] [RFC PATCH 0/4]: Implement module information export

[Neil Horman]

On Wed, May 04, 2016 at 11:16:42PM +0200, Thomas Monjalon wrote:
> This discussion requires more opinions.
> Please everybody, READ and COMMENT. Thanks
> 
> If it is not enough visible, a new thread could be started later.
> 
> 2016-05-04 07:43, Neil Horman:
> > On Wed, May 04, 2016 at 10:24:18AM +0200, David Marchand wrote:
> > > On Tue, May 3, 2016 at 1:57 PM, Neil Horman <nhorman at tuxdriver.com> wrote:
> > > >> 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.
> 
> It is a good point. We need something 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.
> 
> It is also a problem for compilation units having PF and VF drivers.
> 
Thats exactly the problem in the two cases I encountered.  The common code
between the PF and VF drivers was handled by simply building the whole driver
together, which is problematic because it make both drivers bigger than they
need to be.  But its somewhat moot, as the problem is orthogonal to this one if
we have to go with a 'special section' approach to implementing this.

> > > >> But regardless, I thought I would propose this to see what you all thought of
> > > >> it.
> 
> Thanks for proposing.
> 
> > > - 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.
> > 
> > If you're statically linking an application, you should know what hardware you
> > support already.  Its going to be very hard, if not impossible to develop a
> > robust solution that works with static binaries (the prior solutions don't work
> > consistently with static binaries either).  I really think the static solution
> > needs to just be built into the application (i.e. the application needs to add a
> > command line option to dump out the pci id's that are registered).
> 
> No, we need a tool to know what are the supported devices before running
> the application (e.g. for binding).
> This tool should not behave differently depending of how DPDK was compiled
> (static or shared).
> 
Very well.

> [...]
> > > - How does it behave if we strip the dsos ?
> > 
> > I described this above, its invariant to stripping, because the symbols for each
> > pmd are explicitly exported, so strip doesn't touch the symbols that pmdinfo
> > keys off of.
> > 
> [...]
> > > - The tool output format is not script friendly from my pov.
> > 
> > Don't think it really needs to be script friendly, it was meant to provide human
> > readable output, but script friendly output can be added easily enough if you
> > want.
> 
> Yes it needs to be script friendly.
> 
Thats easy enough.

> It appears that we must agree on a set of requirements first.
> Please let's forget the implementation until we have collected enough
> feedbacks on the needs.
> I suggest these items to start the list:
> 
> - query all drivers in static binary or shared library
This does require a some sort of special section then, but thats fine

> - stripping resiliency
easy enough
> - human friendly
done
> - script friendly
Can be done easily
> - show driver name
Thats somewhat orthogonal to this problem, the driver name is codified in the
rte_driver struct, we just have to be sure that driver writers fill that out

> - list supported device id / name
> - list driver options
Hadn't thought of that, but its a good idea.
> - show driver version if available
Can be done.
> - show dpdk version
This is tricky as its not really codified in any DPDK code, especially for DSO's
built independently from the dpdk library

> - show kernel dependencies (vfio/uio_pci_generic/etc)
Same as above, no real way to know that unless driver writers want to manually
call out dependencies.

> - room for extra information?
> 
> Please ack or comment items of this list, thanks.
>