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 7C5C5A046B for ; Tue, 23 Jul 2019 14:30:44 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1BE281C000; Tue, 23 Jul 2019 14:30:44 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id D75381BFFF for ; Tue, 23 Jul 2019 14:30:41 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jul 2019 05:30:40 -0700 X-IronPort-AV: E=Sophos;i="5.64,299,1559545200"; d="scan'208";a="160177189" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.51]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jul 2019 05:30:36 -0700 Date: Tue, 23 Jul 2019 13:30:33 +0100 From: Bruce Richardson To: Stephen Hemminger Cc: Thomas Monjalon , dev@dpdk.org Message-ID: <20190723123033.GA1603@bricha3-MOBL.ger.corp.intel.com> References: <20190715234136.3526-1-stephen@networkplumber.org> <3107061.JzsCpgzbfO@xps> <20190722101316.33121639@xps13> <4987111.cxvgFvst8F@xps> <20190722115326.25a201b8@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190722115326.25a201b8@xps13> User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [PATCH] pci: fix missing pci bus with shared library build 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, Jul 22, 2019 at 11:53:26AM -0700, Stephen Hemminger wrote: > On Mon, 22 Jul 2019 19:31:08 +0200 > Thomas Monjalon wrote: > > > 22/07/2019 19:13, Stephen Hemminger: > > > Thomas Monjalon wrote: > > > > Are the constructors run on dlopen of the bus driver? > > > > > > Yes, constructors are run on dlopen. > > > But application should not have to ask DPDK to dlopen the bus devices. > > > > > > The core principle is that dynamic build of DPDK should act the same as old > > > statically linked DPDK. Otherwise, the user experience is even worse, and all > > > the example documentation is wrong. > > > > OK, this is where I wanted to bring the discussion. > > You are arguing against a design which is in DPDK from some early days. > > So this is an interesting discussion to have. > > Do we want to change the "plugin model" we have? > > Or do we want to simply drop this model (dlopen calls) > > and replace it with strong dynamic linking? > > > > > > What I think should happen (and isn't is): > > 1. The PCI bus library is linked with --whole-archive, and --no-as-needed. > This causes constructor to be called and register the bus. > This should be applied to the whole of the bus drivers, not just the PCI bus. > 2. As part of the build process all the PCI drivers pmdinfo would get > constructed into a table of vendor/device to PMD shared library name. > > 3. PMD's are linked as --whole-archive, and --as-needed. > I'm not sure I agree with this change to always link in all the PMDs. It prevents an app from being used with just a subset of the drivers needed. > 4. New code in PCI probe which looks for existing entries (static or -d) > for devices. If device is still not found it refers to the table of PMD's > (from #2) and calls dlopen for that device (and adds it to static table). > > This would allow examples and customer applications to Just Work without > having to know the PMD that is present. It would also solve the problem > that currently if applications is linked with -ldpdk linker script then > all PMD's get pulled into the application address space. > In all this you seem to be assuming that the drivers are not picked up at runtime from the RTE_EAL_PMD_PATH. In real world cases where a user is building an app, and not developing DPDK itself, the DPDK libraries should be installed in /usr(/local)/lib64 and the drivers in .../lib64/dpdk/dpdk-19.08. In that case, the bus drivers and the PMD drivers are all loaded at runtime for each app, without having any dependency on having a specific one be present, allowing a user to remove any drivers unnecessary for the current hardware. Did you try installing DPDK using "ninja install" or "make install" before running any apps using it? /Bruce