From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 8456E593B for ; Sat, 12 Apr 2014 13:02:53 +0200 (CEST) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1WYvjW-000519-Jf for dev@dpdk.org; Sat, 12 Apr 2014 07:04:31 -0400 Date: Sat, 12 Apr 2014 07:04:25 -0400 From: Neil Horman To: dev@dpdk.org Message-ID: <20140412110425.GB30887@hmsreliant.think-freely.org> References: <1397162846-28912-1-git-send-email-nhorman@tuxdriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1397162846-28912-1-git-send-email-nhorman@tuxdriver.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: -2.9 (--) X-Spam-Status: No Subject: Re: [dpdk-dev] [PATCH 0/19] Separate compile time linkage between eal lib and pmd's X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Apr 2014 11:02:53 -0000 On Thu, Apr 10, 2014 at 04:47:07PM -0400, Neil Horman wrote: > Disconnect compile time linkage between eal library / applications and pmd's > > I noticed that, while tinkering with dpdk, building for shared libraries still > resulted in all the test applications linking to all the built pmd's, despite > not actually needing them all. We are able to tell an application at run time > (via the -d/--blacklist/--whitelist/--vdev options) which pmd's we want to use, and > so have no need to link them at all. The only reason they get pulled in is > because rte_eal_non_pci_init_etherdev and rte_pmd_init_all contain static lists > to the individual pmd init functions. The result is that, even when building as > DSO's, we have to load all the pmd libraries, which is space inefficient and > defeating of some of the purpose of shared objects. > > To correct this, I developed this patch series, which introduces two new macros, > PMD_INIT_NONPCI and PMD_INIT. These two macros use constructors to register > their init routines at runtime, either prior to the execution of main() when > linked statically, or when dlopen is called on a DSO at run time. The result is > that PMD's can be loaded at run time without the application or eal library > having to hold a reference to them. They work in a very simmilar fashion to the > module_init routine in the linux kernel. > > I've tested this feature using the igb and pcap pmd's, both statically and > dynamically linked with the test and testpmd sample applications, and it seems > to work well. > > Note, I encountered a few bugs along the way, which I fixed and noted in the > series. > > Regards > Neil > > Self NAK on this, based on the conversation Thomas and I had about Oliviers patches from a while back, I'm going to rebase and repost these soon. Neil