[dpdk-dev] [PATCH RFC 00/13] Update build system
2015-01-22 10:03, Gonzalez Monroy, Sergio: > > From: Gonzalez Monroy, Sergio > > Sent: Monday, January 12, 2015 5:22 PM > > To: Thomas Monjalon > > Subject: Re: [dpdk-dev] [PATCH RFC 00/13] Update build system > > > > 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. > > > > > > - For shared libraries, explicitly link against dependant > > > >libraries (adding entries to DT_NEEDED). > > > > > > OK, good. > > > > > > > - Update app linking flags against static/shared DPDK libs. > > > > > > > > Note that this patch turns up being quite big because of moving lib > > > > directories to a new subdirectory. > > > > I have ommited the actual diff from the patch doing the move of > > > > librte_eal as it is quite big (6MB). Probably a different approach > > > > is > > > preferred. > > > > > > Why do you think moving directories is needed? > > > > > Actually I am not sure is the best way to do this :) There is no need to > > move > > them, as the same result could be achieved without moving directories, but I > > thought that it would be easier for anyone to see which libraries are 'core' > > and which are not. > > > > Not moving those directories would definitely simplify this patch series. > > > > > Thanks > > > -- > > > Thomas > > > > Thanks, > > Sergio > > Hi Thomas, > > Any other comments/suggestions ? > My main concern would be the patch needed to move librte_eal (around 6MB). > > Thoughts? I think you shouldn't move the libs. Maybe we can link the core libs into one (not sure of the interest) but I think we shouldn't move them in a core/ subdir. On another side, I'd like to see KNI moving out of EAL. -- Thomas
[dpdk-dev] [PATCH RFC 00/13] Update build system
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Thursday, January 22, 2015 10:39 AM > To: Gonzalez Monroy, Sergio > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH RFC 00/13] Update build system > > 2015-01-22 10:03, Gonzalez Monroy, Sergio: > > > From: Gonzalez Monroy, Sergio > > > Sent: Monday, January 12, 2015 5:22 PM > > > To: Thomas Monjalon > > > Subject: Re: [dpdk-dev] [PATCH RFC 00/13] Update build system > > > > > > 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. > > > > > > > > - For shared libraries, explicitly link against dependant > > > > >libraries (adding entries to DT_NEEDED). > > > > > > > > OK, good. > > > > > > > > > - Update app linking flags against static/shared DPDK libs. > > > > > > > > > > Note that this patch turns up being quite big because of moving > > > > > lib directories to a new subdirectory. > > > > > I have ommited the actual diff from the patch doing the move of > > > > > librte_eal as it is quite big (6MB). Probably a different > > > > > approach is > > > > preferred. > > > > > > > > Why do you think moving directories is needed? > > > > > > > Actually I am not sure is the best way to do this :) There is no > > > need to move them, as the same result could be achieved without > > > moving directories, but I thought that it would be easier for anyone to > see which libraries are 'core' > > > and which are not. > > > > > > Not moving those directories would definitely simplify this patch series. > > > > > > > Thanks > > > > -- > > > > Thomas > > > > > > Thanks, > > > Sergio > > > > Hi Thomas, > > > > Any other comments/suggestions ? > > My main concern would be the patch needed to move librte_eal (around > 6MB). > > > > Thoughts? > > I think you shouldn't move the libs. > Maybe we can link the core libs into one (not sure of the interest) but I > think > we shouldn't move them in a core/ subdir. > > On another side, I'd like to see KNI moving out of EAL. > > -- > Thomas I think moving KNI out of EAL belongs to a different patch. We can still link librte_core without moving the directories into core/ I'll work on it. Thanks, Sergio
[dpdk-dev] [PATCH RFC 00/13] Update build system
> From: Gonzalez Monroy, Sergio > Sent: Monday, January 12, 2015 5:22 PM > To: Thomas Monjalon > Subject: Re: [dpdk-dev] [PATCH RFC 00/13] Update build system > > 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. > > > > - For shared libraries, explicitly link against dependant > > >libraries (adding entries to DT_NEEDED). > > > > OK, good. > > > > > - Update app linking flags against static/shared DPDK libs. > > > > > > Note that this patch turns up being quite big because of moving lib > > > directories to a new subdirectory. > > > I have ommited the actual diff from the patch doing the move of > > > librte_eal as it is quite big (6MB). Probably a different approach > > > is > > preferred. > > > > Why do you think moving directories is needed? > > > Actually I am not sure is the best way to do this :) There is no need to move > them, as the same result could be achieved without moving directories, but I > thought that it would be easier for anyone to see which libraries are 'core' > and which are not. > > Not moving those directories would definitely simplify this patch series. > > > Thanks > > -- > > Thomas > > Thanks, > Sergio Hi Thomas, Any other comments/suggestions ? My main concern would be the patch needed to move librte_eal (around 6MB). Thoughts? Thanks, Sergio
[dpdk-dev] [PATCH RFC 00/13] Update build system
On Mon, Jan 12, 2015 at 04:33:53PM +, Sergio Gonzalez Monroy wrote: > This patch series updates the DPDK build system. > > 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. > - Remove config option to build a combined library. > - For shared libraries, explicitly link against dependant >libraries (adding entries to DT_NEEDED). > - Update app linking flags against static/shared DPDK libs. > > Note that this patch turns up being quite big because of moving lib > directories to a new subdirectory. > I have ommited the actual diff from the patch doing the move of librte_eal > as it is quite big (6MB). Probably a different approach is preferred. > > Sergio Gonzalez Monroy (13): > mk: Remove combined library and related options > lib/core: create new core dir and makefiles > core: move librte_eal to core subdir > core: move librte_malloc to core subdir > core: move librte_mempool to core subdir > core: move librte_mbuf to core subdir > core: move librte_ring to core subdir > Update path of core libraries > mk: new corelib makefile > lib: Set LDLIBS for each library > mk: Use LDLIBS when linking shared libraries > mk: update apps build > mk: add -lpthread to linuxapp EXECENV_LDLIBS > Series Acked-by: Neil Horman
[dpdk-dev] [PATCH RFC 00/13] Update build system
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? > - Remove config option to build a combined library. Why removing combined library? Is there people finding it helpful? > - For shared libraries, explicitly link against dependant >libraries (adding entries to DT_NEEDED). OK, good. > - Update app linking flags against static/shared DPDK libs. > > Note that this patch turns up being quite big because of moving lib > directories to a new subdirectory. > I have ommited the actual diff from the patch doing the move of librte_eal > as it is quite big (6MB). Probably a different approach is preferred. Why do you think moving directories is needed? Thanks -- Thomas
[dpdk-dev] [PATCH RFC 00/13] Update build system
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. > > - For shared libraries, explicitly link against dependant > >libraries (adding entries to DT_NEEDED). > > OK, good. > > > - Update app linking flags against static/shared DPDK libs. > > > > Note that this patch turns up being quite big because of moving lib > > directories to a new subdirectory. > > I have ommited the actual diff from the patch doing the move of > > librte_eal as it is quite big (6MB). Probably a different approach is > preferred. > > Why do you think moving directories is needed? > Actually I am not sure is the best way to do this :) There is no need to move them, as the same result could be achieved without moving directories, but I thought that it would be easier for anyone to see which libraries are 'core' and which are not. Not moving those directories would definitely simplify this patch series. > Thanks > -- > Thomas Thanks, Sergio
[dpdk-dev] [PATCH RFC 00/13] Update build system
This patch series updates the DPDK build system. 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. - Remove config option to build a combined library. - For shared libraries, explicitly link against dependant libraries (adding entries to DT_NEEDED). - Update app linking flags against static/shared DPDK libs. Note that this patch turns up being quite big because of moving lib directories to a new subdirectory. I have ommited the actual diff from the patch doing the move of librte_eal as it is quite big (6MB). Probably a different approach is preferred. Sergio Gonzalez Monroy (13): mk: Remove combined library and related options lib/core: create new core dir and makefiles core: move librte_eal to core subdir core: move librte_malloc to core subdir core: move librte_mempool to core subdir core: move librte_mbuf to core subdir core: move librte_ring to core subdir Update path of core libraries mk: new corelib makefile lib: Set LDLIBS for each library mk: Use LDLIBS when linking shared libraries mk: update apps build mk: add -lpthread to linuxapp EXECENV_LDLIBS app/test/test_eal_fs.c | 2 +- config/common_bsdapp | 6 - config/common_linuxapp | 6 - config/defconfig_ppc_64-power8-linuxapp-gcc| 2 - lib/Makefile | 7 +- lib/core/Makefile |43 + lib/core/librte_core/Makefile |45 + lib/core/librte_eal/Makefile |39 + lib/core/librte_eal/bsdapp/Makefile|38 + lib/core/librte_eal/bsdapp/contigmem/BSDmakefile |36 + lib/core/librte_eal/bsdapp/contigmem/Makefile |52 + lib/core/librte_eal/bsdapp/contigmem/contigmem.c | 233 + lib/core/librte_eal/bsdapp/eal/Makefile|97 + lib/core/librte_eal/bsdapp/eal/eal.c | 563 + lib/core/librte_eal/bsdapp/eal/eal_alarm.c |60 + lib/core/librte_eal/bsdapp/eal/eal_debug.c | 113 + lib/core/librte_eal/bsdapp/eal/eal_hugepage_info.c | 133 + lib/core/librte_eal/bsdapp/eal/eal_interrupts.c|71 + lib/core/librte_eal/bsdapp/eal/eal_lcore.c | 107 + lib/core/librte_eal/bsdapp/eal/eal_log.c |57 + lib/core/librte_eal/bsdapp/eal/eal_memory.c| 224 + lib/core/librte_eal/bsdapp/eal/eal_pci.c | 510 + lib/core/librte_eal/bsdapp/eal/eal_thread.c| 233 + lib/core/librte_eal/bsdapp/eal/eal_timer.c | 141 + .../bsdapp/eal/include/exec-env/rte_dom0_common.h | 107 + .../bsdapp/eal/include/exec-env/rte_interrupts.h |54 + lib/core/librte_eal/bsdapp/nic_uio/BSDmakefile |36 + lib/core/librte_eal/bsdapp/nic_uio/Makefile|52 + lib/core/librte_eal/bsdapp/nic_uio/nic_uio.c | 329 + lib/core/librte_eal/common/Makefile|61 + lib/core/librte_eal/common/eal_common_cpuflags.c |85 + lib/core/librte_eal/common/eal_common_dev.c| 109 + lib/core/librte_eal/common/eal_common_devargs.c| 152 + lib/core/librte_eal/common/eal_common_errno.c |74 + lib/core/librte_eal/common/eal_common_hexdump.c| 121 + lib/core/librte_eal/common/eal_common_launch.c | 120 + lib/core/librte_eal/common/eal_common_log.c| 320 + lib/core/librte_eal/common/eal_common_memory.c | 121 + lib/core/librte_eal/common/eal_common_memzone.c| 533 + lib/core/librte_eal/common/eal_common_options.c| 611 ++ lib/core/librte_eal/common/eal_common_pci.c| 207 + lib/core/librte_eal/common/eal_common_string_fns.c |69 + lib/core/librte_eal/common/eal_common_tailqs.c | 146 + lib/core/librte_eal/common/eal_filesystem.h| 118 + lib/core/librte_eal/common/eal_hugepages.h |67 + lib/core/librte_eal/common/eal_internal_cfg.h |93 + lib/core/librte_eal/common/eal_options.h |93 + lib/core/librte_eal/common/eal_private.h | 206 + lib/core/librte_eal/common/eal_thread.h|53 + .../common/include/arch/ppc_64/rte_atomic.h| 426 + .../common/include/arch/ppc_64/rte_byteorder.h | 149 + .../common/include/arch/ppc_64/rte_cpuflags.h | 187 + .../common/include/arch/ppc_64/rte_cycles.h|87 + .../common/include/arch/ppc_64/rte_memcpy.h| 225 + .../common/include/arch/ppc_64/rte_prefetch.h |61 + .../common/include/arch/ppc_64/rte_spinlock.h |73 + .../common/include/arch/x86/rte_atomic.h | 216 + .../common/include/arch/x86/rte_atomic_32.h| 222 + .../common/include/arch/x86/rte_atomic_64.h
[dpdk-dev] [PATCH RFC 00/13] Update build system
On Mon, Jan 12, 2015 at 05:21:48PM +, 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
