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

[Neil Horman]

On Tue, Apr 15, 2014 at 10:31:25AM +0200, Thomas Monjalon wrote:
> 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.
> 
I presume at this point you're fairly close to tagging
1.6.0r2, which, based on what I see in the git tree is usually the last rc
before you merge to the next major version.  Do you want to put this in now,
before that happens, or will you commit to the first 1.7.0 rc?  If the latter,
that seems like the best time to make ABI changes, so you maximize testing

Neil

> Thanks Neil
> -- 
> Thomas
>