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 274DFA046B for ; Tue, 23 Jul 2019 20:47:35 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 40AF71C0BC; Tue, 23 Jul 2019 20:47:34 +0200 (CEST) Received: from mail-pf1-f196.google.com (mail-pf1-f196.google.com [209.85.210.196]) by dpdk.org (Postfix) with ESMTP id 0793B1C0B9 for ; Tue, 23 Jul 2019 20:47:33 +0200 (CEST) Received: by mail-pf1-f196.google.com with SMTP id y15so19585458pfn.5 for ; Tue, 23 Jul 2019 11:47:32 -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=pvYURlffRHxw5gNOIPDfGE191XnziftgtDqYPDnGYss=; b=H61zFznBD44+1zbs5i73bEpz6/fhKz8a0A6IZ2w19ujDd9RyW/YRn1I/ds2Qns+xIo zQG1xeGZhO5YUMALGndnS611c0j5z0VFZ2hqzbWqtFW0W9iDm3cDaM44/FjHj3KPKTlA Z/KhP62NEfpZReBR13aEZAhu3mnUlEr32wu12PaB4O0vyOlOie9dymtrxfJ5iP+V0cAt FCm0CNXoCVL3o9uSPn0umb7T7a8ElipJxDCjhlo03uZEquWCG353icJOOE2cU5LuyIX+ /A7bOkGzu01Evyd09OwmUBZkU6993MK3/LXnJcGoy8X1FVeEmfrcmczmBSYZ8J3gJjRF Bz1g== 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=pvYURlffRHxw5gNOIPDfGE191XnziftgtDqYPDnGYss=; b=JIzKcy47EsWYjYB4yA8P/O6qIhoc9I4M9k0NYjiwXVFWkJ9YWl1i3clu3fT2hHIpzH sRhF5JH3kDU3nbgjaB7MkXxX+TG6gJ15Pb7EnaV0UrAsIPFa0RTL+WxIJw7SjUrJX2Dp 43ydUJrmjUjHoJwnJyDf7LwtSkkBKAsayp/BsXRYfJqlZ+cI94DbNMtzjNQ+aOVl0S7B jwFmbbN6RQgzH2kvAD7Aa7AEcbPUNhXrYGtUXX/6mjDHv3GNio2viD9gj096kZhEeaOd 06tDCJZnT5Dd9u0qYX77ZVGXynAxYNEhm2UAY0qQm6gOt2PYjsIE23F11MhFqJnhAP11 O9/g== X-Gm-Message-State: APjAAAXIkM+S0PN3MJ5Y1P4hyXnI1zgA6WS7ZSfawqSkRJLZmWz6sjJU VeSI49bzJ1Bs/zqsRble1RE= X-Google-Smtp-Source: APXvYqz2FU+v/5OdhPU/v9UcKM/M+VhfUEVSUifpvQgj3zuhme7ve5lHAbDQq2sw1HW8ZxfE9f2Z4Q== X-Received: by 2002:a65:44cc:: with SMTP id g12mr336952pgs.409.1563907652096; Tue, 23 Jul 2019 11:47:32 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id t9sm44082372pji.18.2019.07.23.11.47.31 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 23 Jul 2019 11:47:32 -0700 (PDT) Date: Tue, 23 Jul 2019 11:47:25 -0700 From: Stephen Hemminger To: Bruce Richardson Cc: Thomas Monjalon , dev@dpdk.org Message-ID: <20190723114725.73a9a77f@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. Looking at the plugin loading, the problem is it loads every PMD not just those that are going to be used. Isn't this a problem with a distribution model on an embedded system? Not everyone has virtual memory space to burn.