From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v5 00/14] dpdk: Separate compile time linkage between eal lib and pmd's Date: Tue, 20 May 2014 14:45:09 +0200 Message-ID: <1625721.M2ZgnCqEoJ@xps13> References: <1397585169-14537-1-git-send-email-nhorman@tuxdriver.com> <1398092379-7679-1-git-send-email-nhorman@tuxdriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev-VfR2kkLFssw@public.gmane.org To: Neil Horman Return-path: In-Reply-To: <1398092379-7679-1-git-send-email-nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" 2014-04-21 10:59, Neil Horman: > 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 a new > macro, PMD_REGISTER_DRIVER, which wraps up Oliviers work using constructors > on the virtual device pmds, then expands on it to include the physical > device pmds, allowing us to break linkages between dpdk applications and > pmd's almost entirely (save for the ring and xenvirt drivers, which have > additional api's outside of the standard dpdk code that we need to further > fix). This also allows us to completely remove the rte_pmd_init_all > routine, hiding its function internally to the rte_eal_init path. > > 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. Thanks for this nice cleanup. Acked-by: Thomas Monjalon Applied for version 1.7.0. -- Thomas