DPDK patches and discussions
 help / color / mirror / Atom feed
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
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

             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:

* 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 \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git