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

Thomas Monjalon thomas.monjalon at 6wind.com
Tue May 20 14:45:09 CEST 2014


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.

-- 
Thomas


More information about the dev mailing list