[dpdk-dev] [PATCH v5 00/14] dpdk: Separate compile time linkage between eal lib and pmd's

[Neil Horman]

On Tue, May 20, 2014 at 02:45:09PM +0200, Thomas Monjalon wrote:
> 2014-04-21 10:59, Neil Horman:
> > 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 a new
> > macro, PMD_REGISTER_DRIVER, which wraps up Oliviers work using constructors
> > on the virtual device pmds, then expands on it to include the physical
> > device pmds, allowing us to break linkages between dpdk applications and
> > pmd's almost entirely (save for the ring and xenvirt drivers, which have
> > additional api's outside of the standard dpdk code that we need to further
> > fix).  This also allows us to completely remove the rte_pmd_init_all
> > routine, hiding its function internally to the rte_eal_init path.
> > 
> > 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.
> 
> Thanks for this nice cleanup.
> 
> Acked-by: Thomas Monjalon <thomas.monjalon at 6wind.com>
> 
> Applied for version 1.7.0.
> 
Thank you Thomas, I will pull this into the rpm I have awaiting revew for
Fedora asap.

Neil

> -- 
> Thomas
>