2014-04-12 07:04, Neil Horman: > 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
I'll be glad to get your fixes soon. So I could apply them for version 1.6.0r2 and release it. But I think you should post API changes (if any) in another series. Then we'll think if we want to push it in another branch for next major version. Thanks Neil -- Thomas
