From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6F323A0C4C; Thu, 14 Oct 2021 10:43:10 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 25E1A40042; Thu, 14 Oct 2021 10:43:10 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by mails.dpdk.org (Postfix) with ESMTP id 6DEB640041 for ; Thu, 14 Oct 2021 10:43:08 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10136"; a="207746818" X-IronPort-AV: E=Sophos;i="5.85,372,1624345200"; d="scan'208";a="207746818" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Oct 2021 01:43:06 -0700 X-IronPort-AV: E=Sophos;i="5.85,372,1624345200"; d="scan'208";a="491860544" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.25.39]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 14 Oct 2021 01:43:04 -0700 Date: Thu, 14 Oct 2021 09:43:00 +0100 From: Bruce Richardson To: Stephen Hemminger Cc: Ferruh Yigit , "Burakov, Anatoly" , dev@dpdk.org Message-ID: References: <20211013095218.6ced99fa@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211013095218.6ced99fa@hermes.local> Subject: Re: [dpdk-dev] DPDK driver autoloading? X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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 Wed, Oct 13, 2021 at 09:52:18AM -0700, Stephen Hemminger wrote: > The current DPDK PCI code requires that all PMD shared libraries > be loaded before probing. This a burden for applications that run > on multiple platforms and a total mess for Linux distributions. > > A better way would be to have the bus scanning code autoload > drivers as needed. This would work like the Linux kernel > module loading. > > Could existing pmdinfogen mechanism be extended to to do this? Can you clarify a bit more about what the problem is here? How does EAL loading the modules first make things a mess for distributions, compared to loading them on-demand? With both schemes you naturally need to ensure all needed drivers are present, and can remove any unneeded drivers. The only difference is that with our current scheme some unneeded drivers which are present will be loaded at runtime but idle/unused - hardly a massive impact, I would think. What am I missing here? /Bruce