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
