Re: [dpdk-dev] [PATCH 0/19] Separate compile time linkage between eal lib and pmd's

[Neil Horman <nhorman@tuxdriver.com>]

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