From: "Pai G, Sunil" <sunil.pai.g@intel.com>
To: "Richardson, Bruce" <bruce.richardson@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: "Richardson, Bruce" <bruce.richardson@intel.com>,
"Stokes, Ian" <ian.stokes@intel.com>
Subject: Re: [dpdk-dev] [PATCH] eal: don't use default library path for static binaries
Date: Tue, 30 Jun 2020 15:39:02 +0000 [thread overview]
Message-ID: <MWHPR11MB18052D3AB53049C1894E69E0BD6F0@MWHPR11MB1805.namprd11.prod.outlook.com> (raw)
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Bruce Richardson
> Sent: Friday, June 26, 2020 8:30 PM
> To: dev@dpdk.org
> Cc: Richardson, Bruce <bruce.richardson@intel.com>
> Subject: [dpdk-dev] [PATCH] eal: don't use default library path for static
> binaries
>
> When using statically linked DPDK binaries, the EAL checks the default PMD
> path and tries to load any drivers there, despite the fact that all drivers are
> normally linked into the binary. This behaviour can cause issues if the PMD
> path and lib dir is configured to a non-standard location which is not in the
> ld.so.conf paths, e.g. a build with prefix set to a home directory location. In a
> case such as this, EAL will try and
> (unnecessarily) load the .so driver files but that load will fail as their
> dependent libraries, such as ethdev, for example, will not be found.
>
> Because of this, it is better if statically linked DPDK apps do not load drivers
> from the standard paths automatically. The user can always have this
> behaviour by explicitly specifying the path using -d flag, if so desired.
>
> Not loading the libraries automatically can also prevent potential issues with a
> user building and running a statically-linked DPDK binary based off a private
> copy of DPDK, while there exists on the same machine a system-wide
> installation of DPDK in the default locations. Without this change, the system-
> installed drivers will be loaded to the binary alongside the statically-linked
> drivers, which is not what the user would have intended.
>
> To detect whether we are in a statically or dynamically linked binary, we can
> have EAL try to get a dlopen handle to its own shared library, by calling
> dlopen with the RTLD_NOLOAD flag. This will return NULL if there is no such
> shared lib loaded i.e. the code is executing from a static library, or a handle to
> the lib if it is loaded.
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
> lib/librte_eal/common/eal_common_options.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/lib/librte_eal/common/eal_common_options.c
> b/lib/librte_eal/common/eal_common_options.c
> index 0901b493c..1d958d11e 100644
> --- a/lib/librte_eal/common/eal_common_options.c
> +++ b/lib/librte_eal/common/eal_common_options.c
> @@ -447,8 +447,15 @@ eal_plugins_init(void)
> struct shared_driver *solib = NULL;
> struct stat sb;
>
> - if (*default_solib_dir != '\0' && stat(default_solib_dir, &sb) == 0 &&
> - S_ISDIR(sb.st_mode))
> + /* if we are not statically linked, add default driver loading
> + * path if it exists as a directory.
> + * (Using dlopen with NOLOAD flag on eal, will return NULL if the eal
> + * shared library is not already loaded i.e. it's statically linked.)
> + */
> + if (dlopen("librte_eal.so", RTLD_LAZY | RTLD_NOLOAD) != NULL &&
> + *default_solib_dir != '\0' &&
> + stat(default_solib_dir, &sb) == 0 &&
> + S_ISDIR(sb.st_mode))
> eal_plugin_add(default_solib_dir);
>
> TAILQ_FOREACH(solib, &solib_list, next) {
> --
> 2.25.1
While trying to enable DPDK meson build for OVS , this patch turned out to be quite beneficial when DPDK was installed using a prefix.
This fixes the "Cannot open shared object file: No such file or directory" seen when OVS is built with static DPDK libraries.
Tested following scenarios with the patch and all of them function as expected:
1. system installed - OVS with DPDK static libs
2. system installed - OVS with DPDK shared libs
3. directory installed using the prefix - OVS with DPDK static libs
4. directory installed using the prefix - OVS with DPDK shared libs
OVS community would be grateful if this could be back ported to 19.11
Acked-by: Sunil Pai G <sunil.pai.g@intel.com
next reply other threads:[~2020-06-30 15:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-30 15:39 Pai G, Sunil [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-06-26 14:59 Bruce Richardson
2020-06-26 17:05 ` Stephen Hemminger
2020-06-29 9:11 ` Bruce Richardson
2020-06-29 9:19 ` Bruce Richardson
2020-06-29 15:41 ` Stephen Hemminger
2020-06-29 16:15 ` Bruce Richardson
2020-07-05 18:01 ` Thomas Monjalon
2020-06-29 14:53 ` Burakov, Anatoly
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=MWHPR11MB18052D3AB53049C1894E69E0BD6F0@MWHPR11MB1805.namprd11.prod.outlook.com \
--to=sunil.pai.g@intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=ian.stokes@intel.com \
/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).