From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4F7B9A0350; Mon, 29 Jun 2020 11:19:19 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1FA431B9BF; Mon, 29 Jun 2020 11:19:19 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 756A01B13C for ; Mon, 29 Jun 2020 11:19:17 +0200 (CEST) IronPort-SDR: vqg3yPp1LDMXtj4edaWijX74c8YA0D0sghqbUkkYJfJBb3cF5YlUSE7SIPO7jF0LVJYksw8gmx kC7Iwy5YpcXA== X-IronPort-AV: E=McAfee;i="6000,8403,9666"; a="230756646" X-IronPort-AV: E=Sophos;i="5.75,294,1589266800"; d="scan'208";a="230756646" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jun 2020 02:19:15 -0700 IronPort-SDR: 1md71k0FFc8y/bERx1c8xdBaPJ1iJdh64o673YeQ5iGQ+r68psBXy4nWMsnDj5satRKZoI6DsI DWSRy1As4e5g== X-IronPort-AV: E=Sophos;i="5.75,294,1589266800"; d="scan'208";a="454129569" Received: from bricha3-mobl.ger.corp.intel.com ([10.251.82.47]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 29 Jun 2020 02:19:14 -0700 Date: Mon, 29 Jun 2020 10:19:10 +0100 From: Bruce Richardson To: Stephen Hemminger Cc: dev@dpdk.org Message-ID: <20200629091910.GB572@bricha3-MOBL.ger.corp.intel.com> References: <20200626145957.722089-1-bruce.richardson@intel.com> <20200626100542.1c87c2c9@hermes.lan> <20200629091158.GA572@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200629091158.GA572@bricha3-MOBL.ger.corp.intel.com> Subject: Re: [dpdk-dev] [PATCH] eal: don't use default library path for static binaries X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Mon, Jun 29, 2020 at 10:11:58AM +0100, Bruce Richardson wrote: > On Fri, Jun 26, 2020 at 10:05:42AM -0700, Stephen Hemminger wrote: > > On Fri, 26 Jun 2020 15:59:57 +0100 > > Bruce Richardson wrote: > > > > > 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 > > > > But what if the majority of the DPDK is statically linked but the > > application wants also load a dynamically linked driver? > > > They use the -d flag as now. The only change here is that we don't > *automatically* (and silently) attempt to load all drivers from a system > location when you have a static binary. I'd also make a couple of additional points: 1. If you have a static app and you have extra drivers in your EAL_PMD_PATH directory you have no way of preventing the loading of them. 2. Since all DPDK apps try to load all files in that directory, all one has to do is put a non-loadable file into the DPDK PMD directory and suddenly all DPDK apps on the system will fail to run. [Patchset http://patches.dpdk.org/project/dpdk/list/?series=10553 will also help here] 3. Since this is a behaviour change, perhaps it needs to be deferred to 20.11? Ideally I think we should fix this now, because I think the current behaviour doesn't make sense and causes more problems than it solves, but if it needs to be deferred, so be it. /Bruce