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

[Thomas Monjalon <thomas.monjalon@6wind.com>]

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