Re: [dpdk-dev] [dpdk-users] If shared libraries are used vdev doesn't work anymore

["Gaëtan Rivet" <gaetan.rivet@6wind.com>]

Hi,

On Mon, Jul 31, 2017 at 10:23:50PM +0200, Thomas Monjalon wrote:
> 31/07/2017 16:58, Dirk-Holger Lenz:
> > If dpdk is built with 'CONFIG_RTE_BUILD_SHARED_LIB=y' then
> > using the vdev feature (args: e.g. -c 3 -n 4 --vdev="crypto_openssl")
> > the rte_eal_init() returns 'ERROR: failed to parse device "crypto_openssl"'.
> > It looks to me that rte_eal_devargs_add() calling rte_eal_devargs_parse()
> > is trying to check the device name before the shared libraries are read
> > and the internal data arrays are setup.
> 
> Yes, you're right: eal_parse_args() is called before eal_plugins_init().
> The fix is not small: we should split the args parsing to parse the
> device arguments after loading shared libraries.
> 
> It is a release blocker.

I saw that yesterday, tried to investigate a bit.
I have currently an issue when launching testpmd when
BUILD_SHARED_LIB=y. Mbufs fail to be allocated. I was not able to find
the root cause for this.

Anyway, I guess there are two possible solutions:

  - Delayed device validation
  - Earlier plugins init

Thomas you seem to propose the first one, I agree that it will probably
be a little involved to implement but I guess it's feasible in time.
However, I don't yet understand why the second one is not possible from
the get-go. It makes sense in any case that the system should be
stabilized as soon as possible - i.e. that underlying subsystems such as
plugins and capabilities are loaded first to expose a stable set of
capabilities to any subsequent initializations.

So, I will lack time to investigate the issue with testpmd and shared
libs. If anyone has any idea, I will gladly hear it. In the meantime, I
will test those two solutions, see what would be feasible, and try to
propose one shortly.

Regards,
-- 
Gaëtan Rivet
6WIND