On Mon, Jan 12, 2015 at 05:21:48PM +0000, Gonzalez Monroy, Sergio wrote: > Hi Thomas, > > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > Sent: Monday, January 12, 2015 4:52 PM > > > > Hi Sergio, > > > > 2015-01-12 16:33, Sergio Gonzalez Monroy: > > > This patch series updates the DPDK build system. > > > > Thanks for proposing such rework. > > We need discussions on that topic. So I ask some questions below. > > > > > Following are the goals it tries to accomplish: > > > - Create a library containing core DPDK libraries (librte_eal, > > > librte_malloc, librte_mempool, librte_mbuf and librte_ring). > > > The idea of core libraries is to group those libraries that are > > > always required for any DPDK application. > > > > How is it better? Is it only to reduce dependencies lines? > > > In my opinion I think that there are a set of libraries that are always > required > and therefore should be grouped as a single one. > Basically all apps and other DPDK libs would have dependencies to these core > libraries. > > Aside from that, I don't think there is any difference. Note that this > affects shared libraries, > with no difference for apps linked against static libs. > > > > - Remove config option to build a combined library. > > > > Why removing combined library? Is there people finding it helpful? > > > I don't think it makes sense from a shared library point of view, maybe it > does for static? > For example, in the case of shared libraries I think we want to try to avoid > the case where > we have an app linked against librte_dpdk.so, but such library may contain > different libraries > depending on the options that were enabled when the lib was built. > > The core libraries would be that set of libraries that are always required > for an app, and its content > would be fixed regardless of the option libraries (like acl, hash, > distributor, etc.) > We could add more libraries as core if we think it is a better solution, but > the goal should be that > librte_core.so contains the same libraries/API regardless of the system/arch. >
FWIW, I think Sergios approach is likely a good balance. As he notes, mempool, eal, malloc and mbuf are needed for any dpdk application, and have interdepedencies, so it makes sense to link them as a single library. Everything else is optional. For static libraries, you can just add a few extra lines to the linker, but for DSO's you might want the option of not linking against a PMD, option to dynamically load it via the dlopen interface (using the -d option). Theres not much sense in adding those PMD DSO's to a single library just to save a few lines in the makefile there. This approach strikes a good balance, combining items that will have to be linked together anyway, and leaving everying else separate. Neil