[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