DPDK usage discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: "Gaëtan Rivet" <gaetan.rivet@6wind.com>
Cc: Dirk-Holger Lenz <dirk.lenz@ng4t.com>, users@dpdk.org, dev@dpdk.org
Subject: Re: [dpdk-users] If shared libraries are used vdev doesn't work anymore
Date: Tue, 01 Aug 2017 11:32:56 +0200	[thread overview]
Message-ID: <3107053.nrimOLvoz2@xps> (raw)
In-Reply-To: <20170801081759.GO11154@bidouze.vm.6wind.com>

01/08/2017 10:17, Gaëtan Rivet:
> 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.

Have you loaded the mempool driver?

> 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.

The problem is that the plugins initialization depends on tailqs, log
and memory initialization.

> 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.

Thank you

  reply	other threads:[~2017-08-01  9:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-31 14:58 Dirk-Holger Lenz
2017-07-31 15:57 ` Dirk-Holger Lenz
2017-07-31 20:23 ` Thomas Monjalon
2017-08-01  8:17   ` Gaëtan Rivet
2017-08-01  9:32     ` Thomas Monjalon [this message]
2017-08-02 14:11       ` Dirk-Holger Lenz

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=3107053.nrimOLvoz2@xps \
    --to=thomas@monjalon.net \
    --cc=dev@dpdk.org \
    --cc=dirk.lenz@ng4t.com \
    --cc=gaetan.rivet@6wind.com \
    --cc=users@dpdk.org \
    /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).