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 9C17C307 for ; Thu, 10 Apr 2014 22:46:04 +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 1WYLsl-0004ML-TJ; Thu, 10 Apr 2014 16:47:39 -0400 From: Neil Horman To: dev@dpdk.org Date: Thu, 10 Apr 2014 16:47:07 -0400 Message-Id: <1397162846-28912-1-git-send-email-nhorman@tuxdriver.com> X-Mailer: git-send-email 1.8.3.1 X-Spam-Score: -2.9 (--) X-Spam-Status: No Subject: [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: Thu, 10 Apr 2014 20:46:04 -0000 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