[dpdk-dev] error in testpmd when CONFIG_RTE_BUILD_SHARED_LIB=y

[Neil Horman]

On Wed, Apr 12, 2017 at 12:25:34PM +0200, Thomas Monjalon wrote:
> 2017-04-12 11:05, Bruce Richardson:
> > On Wed, Apr 12, 2017 at 04:52:47AM +0000, Shreyansh Jain wrote:
> > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > > > 2017-04-11 14:02, john miller:
> > > > >
> > > > > We are seeing an issue when running from the head of the master branch in
> > > > dpdk-next-net and building with CONFIG_RTE_BUILD_SHARED_LIB=y.   When we run
> > > > testpmd using  -d to point to our PMD we get this error
> > > > >
> > > > > EAL: Error - exiting with code: 1
> > > > >   Cause: Creation of mbuf pool for socket 0 failed: Invalid argument
> > > > >
> > > > > This error occurs as a result of the rte mempool ops table having 0
> > > > entries.  This table is populated from a call to rte_mempool_register_ops().
> > > > This function gets called in rte_mempool_ring.c via the static initialization
> > > > MACRO MEMPOOL_REGISTER_OPS and exists in librte_mempool_ring.so.  However
> > > > this library is not loaded when the rte_eal_init() gets called so the static
> > > > initializers are not yet loaded.
> > > > >
> > > > > I am requesting advice on the proper way to repair this.
> > >  
> > > "-d" the ring library (rte_mempool_ring) - just like any other shared lib.
> > > 
> > 
> > I think this is a bug that should be fixed. The user should not need to
> > have to specify a mempool driver just to get testpmd working, so I think
> > the ring handler as default should be compiled in automatically so as to
> > allow regular mempools to just work as before.
> 
> We thought about it when moving the mempool handler as a driver.
> The common case when using shared libs, is to specify the lib directory
> with -d or with CONFIG_RTE_EAL_PMD_PATH.
> 
> I am not sure we should make an exception for the mempool driver.
> If it is built as a shared library, the only one able to link it is
> the user (who knows where the file is).
> 
> 
> > > This change was done recently to move ring handler into its separate drivers/mempool/ring directory. That also means it no longer is compiled into the librte_mempool.
> > > 
> > > > 
> > > > We should just add a better error message if no mempool driver is available.
> > > 
> > > Yes, that is something to be improved.
> > 
> > This should be fixed by always having a mempool driver installed.
> 
> It is not a matter of having it installed but finding it in the right path.
> A good error message suggesting -d would be OK I think.

Well, ostensibly, the "right path" will either be set by the system, or can be
embedded in the application.  it seems like it would be reasonable during
initalization to dlopen a default mempool driver, should another driver not be
manually loaded, the location for which can either be expressly encoded using
the rpath linker option, or assumed to be installed in the default location set
described by LD_LIBRARY_PATH or the system default paths

Neil