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 8252BA046B for ; Tue, 23 Jul 2019 20:11:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CCB4D1C0AD; Tue, 23 Jul 2019 20:11:23 +0200 (CEST) Received: from mail-pl1-f194.google.com (mail-pl1-f194.google.com [209.85.214.194]) by dpdk.org (Postfix) with ESMTP id 884C01C08E for ; Tue, 23 Jul 2019 20:11:22 +0200 (CEST) Received: by mail-pl1-f194.google.com with SMTP id 4so13928643pld.10 for ; Tue, 23 Jul 2019 11:11:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=lhdjMRN1l1RZCcHP2sEjznqnqHQEifhyMYuQrSeH7QU=; b=u4DU/wAYbtYAtG+6ug54xKrRtJy5+xizNCbqgstCWwIEzOKaZaZUazYURJOnnWfWHL zbE0MwEHR7EWavU+UO0iVUPOx8JyWZHeWj/cRfY041+QhqB+XvLxmdZqvEri1G+4IFeA LqAGBtJ9XsD4yl6nMsVDpALpxxcxwiDTmc1eA2yvYF8K8t9z0wFzon+lvHCYhdvvLUwc nPRHozRGVeXxnMWoJBtfvnj8537r5qYjv4f3AIZGmcEUDj2TxbTUpMLr9PmgMlDbOJRC JvChOCCTOAOYmOHWwAYbKENXkZk8ppkZQN14vUo9c7WPdhag8oPwoIJAZiJ5cW9e+egr guVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=lhdjMRN1l1RZCcHP2sEjznqnqHQEifhyMYuQrSeH7QU=; b=RN+PwtbjuLuvKNDzkdjvHGzdfE/yJMGDQKJhgXsGcTwA0Wk0clrEhVTNPmtdnomnoy deMTvmddRLHt3W5aJp22KMGmenYvf+eFf+MxsTnGV4zXIvlv0+PwuiRgG9j3P+U+PDjx WijFay5fT2MORFwgBsElzWJfTD09TGh88FzN2GCP9y/StdI+ctIvgA/ITjplNJQulwWy 0PFNVgKqv+SIH9O4OKVFabImV1N4kgvTfwul6YppP9iZP4xG/aahpger65GGMjf5ro8Z 5OX30kmMYjHmLHdX5p4ekuzlM96qGCHLxJ3hBwh8jTdxAxe4EpU1DlI9GNXsleQ3QUjG z5gQ== X-Gm-Message-State: APjAAAVTTv8Lv2I1eqieZAlOpRsycMtgRVCO43wBDyHPjIplRNwfN+3y UpLZ5fCjkrkCaZ4LrYCfpwLUFuKV X-Google-Smtp-Source: APXvYqzLM/olaNnYVtoiIM9U0JwOyXF0SItEcCwufJ9Slu8GXhGS7fxkzfh9zQ8qSPphR5ZmTEbhbg== X-Received: by 2002:a17:902:8696:: with SMTP id g22mr79835852plo.249.1563905481735; Tue, 23 Jul 2019 11:11:21 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id 125sm58288828pfg.23.2019.07.23.11.11.21 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 23 Jul 2019 11:11:21 -0700 (PDT) Date: Tue, 23 Jul 2019 11:11:14 -0700 From: Stephen Hemminger To: Bruce Richardson Cc: Thomas Monjalon , dev@dpdk.org Message-ID: <20190723111114.4c9b54ad@hermes.lan> In-Reply-To: <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> <20190723123033.GA1603@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Tue, 23 Jul 2019 13:30:33 +0100 Bruce Richardson wrote: > 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 I was using "make install-runtime" into a local chroot directory like a distribution package builder does. There are multiple use cases: 1. Developer build DPDK and application together on one machine (and running on another). Or software appliance being built on one machine and run in many environments. Also cross builds are like this. 2. Distribution building a package (and installing in standard library locations /lib etc). 3. Demo machine where build is local and native. DPDK seems to always focus on #3 which is least interesting for real production.