DPDK usage discussions
 help / color / mirror / Atom feed
From: Panu Matilainen <pmatilai@redhat.com>
To: apanda@cs.berkeley.edu
Cc: users@dpdk.org
Subject: Re: [dpdk-users] DPDK 16.04 link changes cause PMD drivers to not be loaded
Date: Thu, 21 Apr 2016 11:56:57 +0300	[thread overview]
Message-ID: <571895D9.3090700@redhat.com> (raw)
In-Reply-To: <5717917D.9030504@cs.berkeley.edu>

On 04/20/2016 05:26 PM, Aurojit Panda wrote:
> I am sorry that is a bit unintuitive considering:
>
> (a) This behavior differs between static and shared builds of DPDK.
>      - In fact this behavior was identical in 2.2, and even in mainline
> before 948fd64befc3726 went in.
> (b) You already know the EAL_PMD_PATH at build time, and it makes it
> quite hard to ship scripts or anything to build DPDK, since now the
> configuration file becomes dependent on location.

The expectation is that shared libraries are installed to a shared, 
known location. Otherwise there's not that much point in using shared 
libraries.

Note that you can also use the EAL option -d to load either single PMDs 
or entire directories at runtime (regardless of EAL_PMD_PATH) so you 
dont have to know the path at build time if that's what bothers you most.

>
> I wonder if you would consider changing this, as it stands just building
> DPDK after setting CONFIG_RTE_SHARED_LIB=y results in a testpmd that
> cannot run.

In shared library configuration, testpmd is not directly runnable 
regardless of the drivers since its missing all the other libraries too:

[pmatilai@sopuli dpdk]$ build/app/testpmd
build/app/testpmd: error while loading shared libraries: 
librte_distributor.so.1.1: cannot open shared object file: No such file 
or directory
[pmatilai@sopuli dpdk]$

You'll need to get those libraries into linkers path anyway, either by 
installing them to a common location or by extending LD_LIBRARY_PATH. In 
either case, you need to know where the libraries are anyway.

All of which is not to say there might not be room for improvement, but 
the linking behavior is not going to change. Again, PMDs are *plugins* 
that are *meant* to be loaded at runtime. That allows for all sorts of 
flexibility especially for packaging and shipping, at some extra cost in 
setup complexity.

For your own purposes, you can of course tweak the linking settings as 
much as you like. Look for "plugins" in mk/rte.app.mk and change the 
shared lib condition on the line above to "y" and there you have it. But 
that's not the way plugins are meant to be used.

Oh and BTW, please don't top-post.

	- Panu -

  reply	other threads:[~2016-04-21  8:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-19  1:42 Aurojit Panda
2016-04-20  8:32 ` Panu Matilainen
2016-04-20 14:26   ` Aurojit Panda
2016-04-21  8:56     ` Panu Matilainen [this message]
2016-04-21 15:01       ` Aurojit Panda
  -- strict thread matches above, loose matches on Subject: below --
2016-04-19  1:38 Aurojit Panda

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=571895D9.3090700@redhat.com \
    --to=pmatilai@redhat.com \
    --cc=apanda@cs.berkeley.edu \
    --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).