[dpdk-dev] [PATCHv2 4/4] pmdinfo.py: Add tool to query binaries for hw and other support information

[Neil Horman]

On Fri, May 20, 2016 at 08:22:34AM +0300, Panu Matilainen wrote:
> On 05/19/2016 03:00 PM, Neil Horman wrote:
> > On Thu, May 19, 2016 at 12:02:27PM +0300, Panu Matilainen wrote:
> > > On 05/19/2016 12:08 AM, 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
> > > > 
> > > > Note that, in the case of dynamically linked applications, pmdinfo.py will scan
> > > > for implicitly linked PMDs by searching the specified binaries .dynamic section
> > > > for DT_NEEDED entries that contain the substring librte_pmd.  The DT_RUNPATH,
> > > > LD_LIBRARY_PATH, /usr/lib and /lib are searched for these libraries, in that
> > > > order
> > > 
> > > Scanning /usr/lib and /lib does little good on systems where /usr/lib64 and
> > > /lib64 are the standard path, such as x86_64 Fedora / RHEL and derivates.
> > > 
> > Ah, sorry, forgot the 64 bit variants, I can add those in.
> > 
> > > With the path changed (or LD_LIBRARY_PATH set manually), I can confirm it
> > > works for a shared binary which is --whole-archive linked to all of DPDK
> > > such as ovs-vswitchd currently is (because it needs to for static DPDK
> > > linkage and is not aware of plugin autoloading).
> > > 
> > Right, thats why it works, because DPDK always requires --whole-archive for
> > static linking, and likely always will (see commit
> > 20afd76a504155e947c770783ef5023e87136ad8)
> > 
> > > It doesn't help testpmd though because its not linked with --whole-archive
> > > in the shared case, so its not working for the main DPDK executable...
> > > 
> > This sentence doesn't make sense --whole-archive is only applicable in the
> > static binary case, and only when linking archive files.
> 
> Okay sorry I was indeed mixing up things here.
> 
> 1) Testpmd doesn't get linked to those pmds at all, because of this in
> mk/rte.app.mk:
> 
> ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),n)
> # plugins (link only if static libraries)
> ...
> endif
> 
> 2) I'm could swear I've seen --whole-archive it make a difference on newer
> toolchains with the linker script, but I can't reproduce that now no matter
> what. Must've been hallucinating ;)
> 
I think so.  DSO's don't really mesh with the concept of --whole-archive because
they automatically keep their entire contents (since you won't know what symbols
a given application will use at run time)

> > 
> > > In any case, using --whole-archive is a sledgehammer solution at best, and
> > > against the spirit of shared libs and plugins in particular.
> > > 
> > It may be a sledgehammer solution, but its the one dpdk uses, and will likely
> > use in perpituity.
> > 
> > > I think the shared linkage case can be solved by exporting the PMD path from
> > > librte_eal (either through an elf section or c-level symbol) and teach the
> > > script to detect the case of an executable dynamically linked to librte_eal,
> > > fish the path from there and then process everything in that path.
> > > 
> > I really disagree with this, because its a half-measure at best.  Yes, if its
> > set, you will definately get all the shared objects in that directory loaded,
> > but that is in no way a guarantee that those are the only libraries that get
> > loaded (the application may load its own independently).
> 
> That is in no way different from statically linked apps loading additional
> drivers with the EAL -d switch.
> 


Sooo....we agree?

> > So you're left in this
> > situation in which you get maybe some of the hardware support an application
> > offers.  Its also transient.  That is to say, if you configure a plugin
> > directory and search it when you scan an application, its contents may change
> > post scan, leading to erroneous results.
> 
> Yes, changing system state such as installing or removing packages between
> scanning and running can "do stuff" such as change results. People are quite
> aware of this because that's how a huge number of things in the system
> works, you install plugins for multimedia formats you need, maybe remove
> others you dont to clean up system etc. I fail to see how that is a problem
> when it's the expected behavior with plugins.
> 
> > The way I see it, we have 3 cases that we need to handle:
> > 
> > 1) Statically linked application - in this case, all pmds that are statically
> > linked in to the application will be reported, so we're good here
> > 
> > 2) Dynamically loaded via DT_NEEDED entries - This is effectively the same as a
> > static linking case, in that we have a list of libraries that must be resolved
> > at run time, so we are safe to search for and scan the DSO's that the
> > application ennumerates
> > 
> > 3) Dynamically loaded via dlopen - In this case, we don't actually know until
> > runtime what DSO's are going to get loaded, even if RTE_EAL_PMD_PATH is set,
> > because the contents of that path can change at arbitrary times.  In this case,
> > its correct to indicate that the application itself _doesn't_ actually support
> > the hardware of the PMD's in that path, because until the application is
> > executed, it has none of the support embodied in any DSO that it loads via
> > dlopen.  The hardware support travels with the DSO itself, and so its correct to
> > only display hardware support when the PMD shared library itself is scanned.
> > 
> > Handling case 3 the way I'm proposing is exactly the way the OS does it (that is
> > to say, it only details hardware support for the module being queried, and you
> > have to specify the module name to get that).  I don't see there being any
> > problem with that.
> 
> Ability to query individual DSOs is a building block for other things like
> automation (you dont expect normal users to go manually loading hw support
> modules for the OS either), but its not an end-user solution.
> 
> Thomas said in http://dpdk.org/ml/archives/dev/2016-May/038324.html:
> 
> "This tool should not behave differently depending of how DPDK was compiled
> (static or shared)."
> 
> Its entirely possible to handle all the three above cases virtually
> identically (point the tool to the app executable), so I have a hard time
> understanding the level of resistance to handling the plugin case.
> 
Because you're applying some meaning to the idea that Thomas listed, and
it simply doesn't work like that.  Look, try it by using this statement:

"pmdinfo.py lists hardware support that an application has at run time"

Using that statement:

1) Any pmd that is statically linked into the application is guaranteed to be
present at run time, and so is reported

2) Any pmd that is dynamically linked at link time is guarateed to be available
at run time (because the DT_NEEDED entry implies that said pmd has to be loaded
for the application to run), and so the hw support is reported

3) Any pmd that is dynamically loaded via the the RTE_EAL_PMD_PATH or the -d
command line option is _not_ guaranteed to be there at run time, and so is not
reported.

The only reason that your argument about automatically scanning stuff in the
plugin directory makes sense is because you're enforcing the assumption that the
contents of that directory remain unchanged between scan time and run time.  If
thats true great, if not, we get incorrect resulsts.  And we don't address the
-d option at all.

If you want to make the consistency argument, I assert that what we have now is
in fact the most consistent solution.

Please see my elarier email for a compromise solution I'm willing to implement

Neil