[dpdk-dev] [RFC PATCH] replace DPDK config and build system

[dpdk-dev] [RFC PATCH] replace DPDK config and build system

[Bruce Richardson]

Hi all,

following on from the pressing need to add support in DPDK for detecting
and managing external dependencies, I undertook to see what options we had.
However, unrelated to this, over time, I have become increasingly
frustrated by the complexity of the DPDK configuration and build system. As
such, I feel that looking at some of the newer build tools that are out
there might give us the additional functionality we want, along with other
benefits. As such, I undertook a prototype using "meson"[1] for
configuration, which uses "ninja" as a backend for doing the actual build.

With these tools we get the following benefits (not a complete list):
* support for detecting dependencies on the system
* support for detecting compiler features, including functions, defines
* improved maintainability through a high-level language, which gives
  decent error messages including line numbers (!!)
* co-existence with the existing makefile system without making any changes
  to it
* faster builds using ninja - on my many-core system, the builds seem
  significantly faster than with our existing system. Especially in the
  nothing-has-changed case, builds with my prototype return instantly,
  compared to taking a few seconds to recursively check each directory with
  the current build system
* the ability to switch to using a standard "ninja" + "ninja install" setup
* the chance to rework our existing build-config files, and hopefully
  pretty much remove them.
* pkg-config support.
* we get to move away from our bespoke build system
* dependencies in each lib can be moved back to being tracked in the libs
  files themselves, not up a level


Of course, it's not a panacea, but having spent hours on the prototype thus
far, I find working with meson and ninja far more user-friendly than
working on our makefiles, and again the build speed is a really nice
improvment too.

The prototype is incomplete, but it does build a reasonable number of our
libraries, some unit tests, the i40e PMD and the testpmd binary, and I have
successfully passed traffic using testpmd from the build. Some things are
not fully correct, e.g. static builds aren't working right now, as I haven't
correctly done all the dependency tracking, I think, and the cpu flag
detection has issues. It also has only been tried on x86_64 linux, on a
couple of systems, so YMMV. However, I feel it's a reasonable enough start
point to show what we might be able to achieve.

Please take the prototype and test it out. I think it's a better
alternative to trying to bolt on additional functionality to our existing
config and build system.

[1] http://mesonbuild.com/

Bruce Richardson (1):
  build for DPDK with meson and ninja

 .gitignore                                         |  2 +
 app/meson.build                                    |  1 +
 app/test-pmd/meson.build                           | 20 +++++++
 config/meson.build                                 |  5 ++
 config/rte_config.h                                | 20 +++++++
 drivers/mempool/meson.build                        |  2 +
 drivers/mempool/ring/meson.build                   |  9 +++
 drivers/mempool/stack/meson.build                  |  9 +++
 drivers/meson.build                                |  2 +
 drivers/net/i40e/meson.build                       | 61 +++++++++++++++++++
 drivers/net/meson.build                            |  1 +
 lib/librte_acl/meson.build                         | 44 ++++++++++++++
 lib/librte_cmdline/meson.build                     | 30 ++++++++++
 lib/librte_compat/meson.build                      |  4 ++
 lib/librte_eal/common/arch/x86/meson.build         |  1 +
 lib/librte_eal/common/arch/x86_64                  |  1 +
 lib/librte_eal/common/eal_common_cpuflags.c        |  1 +
 lib/librte_eal/common/include/arch/x86/meson.build | 16 +++++
 lib/librte_eal/common/include/arch/x86_64          |  1 +
 lib/librte_eal/common/include/meson.build          | 36 +++++++++++
 lib/librte_eal/common/include/rte_common.h         |  1 +
 lib/librte_eal/common/include/rte_eal.h            |  2 +-
 lib/librte_eal/linuxapp/eal/eal.c                  |  6 +-
 lib/librte_eal/linuxapp/eal/eal_pci_uio.c          |  9 +--
 lib/librte_eal/linuxapp/eal/meson.build            | 57 ++++++++++++++++++
 lib/librte_eal/linuxapp/meson.build                |  1 +
 lib/librte_eal/meson.build                         | 10 ++++
 lib/librte_ether/meson.build                       | 16 +++++
 lib/librte_hash/meson.build                        | 21 +++++++
 lib/librte_kvargs/meson.build                      | 10 ++++
 lib/librte_mbuf/meson.build                        | 10 ++++
 lib/librte_mbuf/rte_mbuf.h                         |  1 +
 lib/librte_mempool/meson.build                     | 10 ++++
 lib/librte_metrics/meson.build                     | 10 ++++
 lib/librte_net/meson.build                         | 19 ++++++
 lib/librte_ring/meson.build                        | 10 ++++
 lib/meson.build                                    | 12 ++++
 meson.build                                        | 70 ++++++++++++++++++++++
 meson_options.txt                                  |  2 +
 test/meson.build                                   |  1 +
 test/test/meson.build                              | 23 +++++++
 test/test/test.c                                   | 17 +++---
 42 files changed, 568 insertions(+), 16 deletions(-)
 create mode 100644 app/meson.build
 create mode 100644 app/test-pmd/meson.build
 create mode 100644 config/meson.build
 create mode 100644 config/rte_config.h
 create mode 100644 drivers/mempool/meson.build
 create mode 100644 drivers/mempool/ring/meson.build
 create mode 100644 drivers/mempool/stack/meson.build
 create mode 100644 drivers/meson.build
 create mode 100644 drivers/net/i40e/meson.build
 create mode 100644 drivers/net/meson.build
 create mode 100644 lib/librte_acl/meson.build
 create mode 100644 lib/librte_cmdline/meson.build
 create mode 100644 lib/librte_compat/meson.build
 create mode 100644 lib/librte_eal/common/arch/x86/meson.build
 create mode 120000 lib/librte_eal/common/arch/x86_64
 create mode 100644 lib/librte_eal/common/include/arch/x86/meson.build
 create mode 120000 lib/librte_eal/common/include/arch/x86_64
 create mode 100644 lib/librte_eal/common/include/meson.build
 create mode 100644 lib/librte_eal/linuxapp/eal/meson.build
 create mode 100644 lib/librte_eal/linuxapp/meson.build
 create mode 100644 lib/librte_eal/meson.build
 create mode 100644 lib/librte_ether/meson.build
 create mode 100644 lib/librte_hash/meson.build
 create mode 100644 lib/librte_kvargs/meson.build
 create mode 100644 lib/librte_mbuf/meson.build
 create mode 100644 lib/librte_mempool/meson.build
 create mode 100644 lib/librte_metrics/meson.build
 create mode 100644 lib/librte_net/meson.build
 create mode 100644 lib/librte_ring/meson.build
 create mode 100644 lib/meson.build
 create mode 100644 meson.build
 create mode 100644 meson_options.txt
 create mode 100644 test/meson.build
 create mode 100644 test/test/meson.build

-- 
2.9.4

[dpdk-dev] [RFC PATCH] build for DPDK with meson and ninja

[Bruce Richardson]

to use, need to have meson >= 0.4 and ninja-build packages installed.

Then do the following in main DPDK directory:

meson build
cd build
ninja
sudo ninja install

This will compile up some DPDK libs, the FVL PMD and testpmd and install
them in /usr/local/. [On Fedora you will need to add /usr/local/lib64 to
your ld path, it's not there by default.]
Then you can run testpmd as e.g.

sudo /usr/local/bin/dpdk-testpmd -c F00000 -- --rxd=512 --txd=512 --rxq=2 --txq=2
---
 .gitignore                                         |  2 +
 app/meson.build                                    |  1 +
 app/test-pmd/meson.build                           | 20 +++++++
 config/meson.build                                 |  5 ++
 config/rte_config.h                                | 20 +++++++
 drivers/mempool/meson.build                        |  2 +
 drivers/mempool/ring/meson.build                   |  9 +++
 drivers/mempool/stack/meson.build                  |  9 +++
 drivers/meson.build                                |  2 +
 drivers/net/i40e/meson.build                       | 61 +++++++++++++++++++
 drivers/net/meson.build                            |  1 +
 lib/librte_acl/meson.build                         | 44 ++++++++++++++
 lib/librte_cmdline/meson.build                     | 30 ++++++++++
 lib/librte_compat/meson.build                      |  4 ++
 lib/librte_eal/common/arch/x86/meson.build         |  1 +
 lib/librte_eal/common/arch/x86_64                  |  1 +
 lib/librte_eal/common/eal_common_cpuflags.c        |  1 +
 lib/librte_eal/common/include/arch/x86/meson.build | 16 +++++
 lib/librte_eal/common/include/arch/x86_64          |  1 +
 lib/librte_eal/common/include/meson.build          | 36 +++++++++++
 lib/librte_eal/common/include/rte_common.h         |  1 +
 lib/librte_eal/common/include/rte_eal.h            |  2 +-
 lib/librte_eal/linuxapp/eal/eal.c                  |  6 +-
 lib/librte_eal/linuxapp/eal/eal_pci_uio.c          |  9 +--
 lib/librte_eal/linuxapp/eal/meson.build            | 57 ++++++++++++++++++
 lib/librte_eal/linuxapp/meson.build                |  1 +
 lib/librte_eal/meson.build                         | 10 ++++
 lib/librte_ether/meson.build                       | 16 +++++
 lib/librte_hash/meson.build                        | 21 +++++++
 lib/librte_kvargs/meson.build                      | 10 ++++
 lib/librte_mbuf/meson.build                        | 10 ++++
 lib/librte_mbuf/rte_mbuf.h                         |  1 +
 lib/librte_mempool/meson.build                     | 10 ++++
 lib/librte_metrics/meson.build                     | 10 ++++
 lib/librte_net/meson.build                         | 19 ++++++
 lib/librte_ring/meson.build                        | 10 ++++
 lib/meson.build                                    | 12 ++++
 meson.build                                        | 70 ++++++++++++++++++++++
 meson_options.txt                                  |  2 +
 test/meson.build                                   |  1 +
 test/test/meson.build                              | 23 +++++++
 test/test/test.c                                   | 17 +++---
 42 files changed, 568 insertions(+), 16 deletions(-)
 create mode 100644 app/meson.build
 create mode 100644 app/test-pmd/meson.build
 create mode 100644 config/meson.build
 create mode 100644 config/rte_config.h
 create mode 100644 drivers/mempool/meson.build
 create mode 100644 drivers/mempool/ring/meson.build
 create mode 100644 drivers/mempool/stack/meson.build
 create mode 100644 drivers/meson.build
 create mode 100644 drivers/net/i40e/meson.build
 create mode 100644 drivers/net/meson.build
 create mode 100644 lib/librte_acl/meson.build
 create mode 100644 lib/librte_cmdline/meson.build
 create mode 100644 lib/librte_compat/meson.build
 create mode 100644 lib/librte_eal/common/arch/x86/meson.build
 create mode 120000 lib/librte_eal/common/arch/x86_64
 create mode 100644 lib/librte_eal/common/include/arch/x86/meson.build
 create mode 120000 lib/librte_eal/common/include/arch/x86_64
 create mode 100644 lib/librte_eal/common/include/meson.build
 create mode 100644 lib/librte_eal/linuxapp/eal/meson.build
 create mode 100644 lib/librte_eal/linuxapp/meson.build
 create mode 100644 lib/librte_eal/meson.build
 create mode 100644 lib/librte_ether/meson.build
 create mode 100644 lib/librte_hash/meson.build
 create mode 100644 lib/librte_kvargs/meson.build
 create mode 100644 lib/librte_mbuf/meson.build
 create mode 100644 lib/librte_mempool/meson.build
 create mode 100644 lib/librte_metrics/meson.build
 create mode 100644 lib/librte_net/meson.build
 create mode 100644 lib/librte_ring/meson.build
 create mode 100644 lib/meson.build
 create mode 100644 meson.build
 create mode 100644 meson_options.txt
 create mode 100644 test/meson.build
 create mode 100644 test/test/meson.build

diff --git a/.gitignore b/.gitignore
index 6df5ba0..e474259 100644
--- a/.gitignore
+++ b/.gitignore
@@ -12,3 +12,5 @@ GPATH
 GRTAGS
 tags
 TAGS
+build
+x86_64-native-linuxapp-gcc
diff --git a/app/meson.build b/app/meson.build
new file mode 100644
index 0000000..b6d9882
--- /dev/null
+++ b/app/meson.build
@@ -0,0 +1 @@
+subdir('test-pmd')
diff --git a/app/test-pmd/meson.build b/app/test-pmd/meson.build
new file mode 100644
index 0000000..bd6874b
--- /dev/null
+++ b/app/test-pmd/meson.build
@@ -0,0 +1,20 @@
+executable('dpdk-testpmd',
+	sources: [
+	'cmdline.c',
+	'cmdline_flow.c',
+	'config.c',
+	'csumonly.c',
+	'flowgen.c',
+	'icmpecho.c',
+	'ieee1588fwd.c',
+	'iofwd.c',
+	'macfwd.c',
+	'macswap.c',
+	'parameters.c',
+	'rxonly.c',
+	'testpmd.c',
+	'txonly.c'
+	],
+	dependencies: [rte_eal, rte_ring, rte_mempool, rte_cmdline,
+		rte_mbuf, rte_net, rte_ether, rte_acl, rte_metrics],
+	install: true)
diff --git a/config/meson.build b/config/meson.build
new file mode 100644
index 0000000..40af994
--- /dev/null
+++ b/config/meson.build
@@ -0,0 +1,5 @@
+dpdk_conf.set('RTE_EAL_PMD_PATH',
+	'"@0@/dpdk/drivers"'.format(get_option('prefix')))
+
+configure_file(output: 'rte_build_config.h',
+		configuration: dpdk_conf)
diff --git a/config/rte_config.h b/config/rte_config.h
new file mode 100644
index 0000000..c99f9e5
--- /dev/null
+++ b/config/rte_config.h
@@ -0,0 +1,20 @@
+#include <rte_build_config.h>
+
+#define RTE_CACHE_LINE_SIZE 64
+#define RTE_MAX_LCORE 128
+#define RTE_MAX_NUMA_NODES 8
+#define RTE_MAX_MEMSEG 256
+#define RTE_MAX_MEMZONE 2048
+#define RTE_MAX_TAILQ 32
+#define RTE_LOG_LEVEL RTE_LOG_INFO
+#define RTE_MEMPOOL_CACHE_MAX_SIZE 512
+#define RTE_PKTMBUF_HEADROOM 128
+#define RTE_MBUF_DEFAULT_MEMPOOL_OPS "ring_mp_mc"
+#define RTE_ETHDEV_QUEUE_STAT_CNTRS 16
+#define RTE_MAX_QUEUES_PER_PORT 1024
+#define RTE_MAX_ETHPORTS 32
+#define RTE_EAL_VFIO 1
+#define RTE_LIBRTE_I40E_ITR_INTERVAL -1
+#define RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM 4
+#define RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF 64
+#define RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF 4
diff --git a/drivers/mempool/meson.build b/drivers/mempool/meson.build
new file mode 100644
index 0000000..7a4feb6
--- /dev/null
+++ b/drivers/mempool/meson.build
@@ -0,0 +1,2 @@
+subdir('ring')
+subdir('stack')
diff --git a/drivers/mempool/ring/meson.build b/drivers/mempool/ring/meson.build
new file mode 100644
index 0000000..1c17a97
--- /dev/null
+++ b/drivers/mempool/ring/meson.build
@@ -0,0 +1,9 @@
+
+sources = ['rte_mempool_ring.c']
+
+mempool_ring_lib = library('rte_mempool_ring', sources,
+	dependencies: [rte_eal, rte_mempool, rte_ring],
+	install: true,
+	install_dir: 'dpdk/drivers')
+rte_mempool_ring = declare_dependency(link_with: mempool_ring_lib,
+	include_directories: include_directories('.'))
diff --git a/drivers/mempool/stack/meson.build b/drivers/mempool/stack/meson.build
new file mode 100644
index 0000000..18b4315
--- /dev/null
+++ b/drivers/mempool/stack/meson.build
@@ -0,0 +1,9 @@
+
+sources = ['rte_mempool_stack.c']
+
+mempool_stack_lib = library('rte_mempool_stack', sources,
+	dependencies: [rte_eal, rte_mempool, rte_ring],
+	install: true,
+	install_dir: 'dpdk/drivers')
+rte_mempool_stack = declare_dependency(link_with: mempool_stack_lib,
+	include_directories: include_directories('.'))
diff --git a/drivers/meson.build b/drivers/meson.build
new file mode 100644
index 0000000..9eb35ae
--- /dev/null
+++ b/drivers/meson.build
@@ -0,0 +1,2 @@
+subdir('mempool')
+subdir('net')
diff --git a/drivers/net/i40e/meson.build b/drivers/net/i40e/meson.build
new file mode 100644
index 0000000..524de3a
--- /dev/null
+++ b/drivers/net/i40e/meson.build
@@ -0,0 +1,61 @@
+i40e_cflags = ['-DPF_DRIVER',
+	'-DVF_DRIVER',
+	'-DINTEGRATED_VF',
+	'-DX722_A0_SUPPORT']
+
+sources = [
+	'i40e_ethdev.c',
+	'i40e_rxtx.c',
+	'i40e_ethdev_vf.c',
+	'i40e_pf.c',
+	'i40e_fdir.c',
+	'i40e_flow.c',
+	'rte_pmd_i40e.c'
+	]
+
+base_sources = [
+	'base/i40e_adminq.c',
+	'base/i40e_common.c',
+	'base/i40e_dcb.c',
+	'base/i40e_diag.c',
+	'base/i40e_hmc.c',
+	'base/i40e_lan_hmc.c',
+	'base/i40e_nvm.c'
+	]
+
+objs = []
+
+if (host_machine.cpu_family() == 'x86') or (host_machine.cpu_family() == 'x86_64')
+	if dpdk_conf.has('RTE_MACHINE_CPUFLAG_SSE4_1')
+		sources += 'i40e_rxtx_vec_sse.c'
+	else
+		sse_tmplib = static_library('sse_tmp',
+			'i40e_rxtx_vec_sse.c',
+			dependencies: rte_eal,
+			c_args: '-msse4.1')
+		objs += sse_tmplib.extract_objects('i40e_rxtx_vec_sse.c')
+	endif
+endif
+
+install_headers('rte_pmd_i40e.h')
+
+base_lib = static_library('i40e_base', base_sources,
+	dependencies: rte_eal,
+	c_args: [i40e_cflags, '-Wno-sign-compare',
+			'-Wno-unused-value',
+			'-Wno-format',
+			'-Wno-unused-but-set-variable'])
+
+i40e_lib = library('rte_pmd_i40e', sources,
+	include_directories: include_directories('base'),
+	objects: objs,
+	dependencies: [rte_eal, rte_net,
+			rte_mbuf, rte_ether,
+			rte_mempool, rte_ring,
+			rte_hash, rte_kvargs],
+	link_with: base_lib,
+	c_args: i40e_cflags,
+	install: true,
+	install_dir: 'dpdk/drivers')
+i40e_pmd = declare_dependency(link_with: ring_lib,
+	include_directories: include_directories('.'))
diff --git a/drivers/net/meson.build b/drivers/net/meson.build
new file mode 100644
index 0000000..d8afe53
--- /dev/null
+++ b/drivers/net/meson.build
@@ -0,0 +1 @@
+subdir('i40e')
diff --git a/lib/librte_acl/meson.build b/lib/librte_acl/meson.build
new file mode 100644
index 0000000..59fb0e5
--- /dev/null
+++ b/lib/librte_acl/meson.build
@@ -0,0 +1,44 @@
+sources = ['tb_mem.c',
+	'rte_acl.c',
+	'acl_bld.c',
+	'acl_gen.c',
+	'acl_run_scalar.c']
+
+objs = []
+flags = ''
+
+if (host_machine.cpu_family() == 'x86') or (host_machine.cpu_family() == 'x86_64')
+
+	if dpdk_conf.has('RTE_MACHINE_CPUFLAG_SSE4_2')
+		sources += 'acl_run_sse.c'
+	else
+		sse_tmplib = static_library('sse_tmp',
+			'acl_run_sse.c',
+			dependencies: rte_eal,
+			c_args: '-msse4.2')
+		objs += sse_tmplib.extract_objects('acl_run_sse.c')
+	endif
+
+	if dpdk_conf.has('RTE_MACHINE_CPUFLAG_AVX2')
+		sources += 'acl_run_avx2.c'
+		flags += '-DCC_AVX2_SUPPORT'
+	elif cc.has_argument('-mavx2')
+		avx2_tmplib = static_library('avx2_tmp',
+			'acl_run_avx2.c',
+			dependencies: rte_eal,
+			c_args: '-mavx2')
+		objs += avx2_tmplib.extract_objects('acl_run_avx2.c')
+		flags += '-DCC_AVX2_SUPPORT'
+	endif
+endif
+
+install_headers('rte_acl.h', 'rte_acl_osdep.h')
+
+acl_lib = library('rte_acl', sources,
+	objects: objs,
+	c_args: flags,
+	dependencies: rte_eal,
+	install: true)
+
+rte_acl = declare_dependency(link_with: acl_lib,
+	include_directories: include_directories('.'))
diff --git a/lib/librte_cmdline/meson.build b/lib/librte_cmdline/meson.build
new file mode 100644
index 0000000..71acf10
--- /dev/null
+++ b/lib/librte_cmdline/meson.build
@@ -0,0 +1,30 @@
+sources = [ 'cmdline.c',
+	'cmdline_cirbuf.c',
+	'cmdline_parse.c',
+	'cmdline_parse_etheraddr.c',
+	'cmdline_parse_ipaddr.c',
+	'cmdline_parse_num.c',
+	'cmdline_parse_portlist.c',
+	'cmdline_parse_string.c',
+	'cmdline_rdline.c',
+	'cmdline_socket.c',
+	'cmdline_vt100.c']
+
+install_headers('cmdline.h',
+	'cmdline_parse.h',
+	'cmdline_parse_num.h',
+	'cmdline_parse_ipaddr.h',
+	'cmdline_parse_etheraddr.h',
+	'cmdline_parse_string.h',
+	'cmdline_rdline.h',
+	'cmdline_vt100.h',
+	'cmdline_socket.h',
+	'cmdline_cirbuf.h',
+	'cmdline_parse_portlist.h')
+
+cmdline_lib = library('rte_cmdline', sources, dependencies: rte_eal,
+		install: true)
+rte_cmdline = declare_dependency(link_with: cmdline_lib,
+	include_directories: include_directories('.'))
+
+dpdk_conf.set('RTE_LIBRTE_CMDLINE', 1)
diff --git a/lib/librte_compat/meson.build b/lib/librte_compat/meson.build
new file mode 100644
index 0000000..a526a3e
--- /dev/null
+++ b/lib/librte_compat/meson.build
@@ -0,0 +1,4 @@
+
+install_headers('rte_compat.h')
+
+rte_compat = declare_dependency(include_directories: include_directories('.'))
diff --git a/lib/librte_eal/common/arch/x86/meson.build b/lib/librte_eal/common/arch/x86/meson.build
new file mode 100644
index 0000000..459a3fb
--- /dev/null
+++ b/lib/librte_eal/common/arch/x86/meson.build
@@ -0,0 +1 @@
+arch_common = files('rte_spinlock.c', 'rte_cpuflags.c')
diff --git a/lib/librte_eal/common/arch/x86_64 b/lib/librte_eal/common/arch/x86_64
new file mode 120000
index 0000000..ef2bea7
--- /dev/null
+++ b/lib/librte_eal/common/arch/x86_64
@@ -0,0 +1 @@
+x86/
\ No newline at end of file
diff --git a/lib/librte_eal/common/eal_common_cpuflags.c b/lib/librte_eal/common/eal_common_cpuflags.c
index 9a2d080..2fb62dd 100644
--- a/lib/librte_eal/common/eal_common_cpuflags.c
+++ b/lib/librte_eal/common/eal_common_cpuflags.c
@@ -33,6 +33,7 @@
 
 #include <stdio.h>
 
+#include <rte_config.h>
 #include <rte_common.h>
 #include <rte_cpuflags.h>
 
diff --git a/lib/librte_eal/common/include/arch/x86/meson.build b/lib/librte_eal/common/include/arch/x86/meson.build
new file mode 100644
index 0000000..ba08290
--- /dev/null
+++ b/lib/librte_eal/common/include/arch/x86/meson.build
@@ -0,0 +1,16 @@
+install_headers(
+	'rte_atomic_32.h',
+	'rte_atomic_64.h',
+	'rte_atomic.h',
+	'rte_byteorder_32.h',
+	'rte_byteorder_64.h',
+	'rte_byteorder.h',
+	'rte_cpuflags.h',
+	'rte_cycles.h',
+	'rte_io.h',
+	'rte_memcpy.h',
+	'rte_prefetch.h',
+	'rte_rtm.h',
+	'rte_rwlock.h',
+	'rte_spinlock.h',
+	'rte_vect.h')
diff --git a/lib/librte_eal/common/include/arch/x86_64 b/lib/librte_eal/common/include/arch/x86_64
new file mode 120000
index 0000000..ef2bea7
--- /dev/null
+++ b/lib/librte_eal/common/include/arch/x86_64
@@ -0,0 +1 @@
+x86/
\ No newline at end of file
diff --git a/lib/librte_eal/common/include/meson.build b/lib/librte_eal/common/include/meson.build
new file mode 100644
index 0000000..224bcb5
--- /dev/null
+++ b/lib/librte_eal/common/include/meson.build
@@ -0,0 +1,36 @@
+common_headers = [
+	'rte_alarm.h',
+	'rte_branch_prediction.h',
+	'rte_bus.h',
+	'rte_common.h',
+	'rte_debug.h',
+	'rte_devargs.h',
+	'rte_dev.h',
+	'rte_eal.h',
+	'rte_eal_memconfig.h',
+	'rte_errno.h',
+	'rte_hexdump.h',
+	'rte_interrupts.h',
+	'rte_keepalive.h',
+	'rte_launch.h',
+	'rte_lcore.h',
+	'rte_log.h',
+	'rte_malloc.h',
+	'rte_malloc_heap.h',
+	'rte_memory.h',
+	'rte_memzone.h',
+	'rte_pci_dev_feature_defs.h',
+	'rte_pci_dev_features.h',
+	'rte_pci.h',
+	'rte_per_lcore.h',
+	'rte_random.h',
+	'rte_string_fns.h',
+	'rte_tailq.h',
+	'rte_time.h',
+	'rte_vdev.h',
+	'rte_version.h']
+
+install_headers(common_headers)
+install_subdir('generic', install_dir : 'include')
+
+subdir('arch/@0@'.format(host_machine.cpu_family()))
diff --git a/lib/librte_eal/common/include/rte_common.h b/lib/librte_eal/common/include/rte_common.h
index e057f6e..bebe05a 100644
--- a/lib/librte_eal/common/include/rte_common.h
+++ b/lib/librte_eal/common/include/rte_common.h
@@ -50,6 +50,7 @@ extern "C" {
 #include <ctype.h>
 #include <errno.h>
 #include <limits.h>
+#include <rte_config.h>
 
 #ifndef typeof
 #define typeof __typeof__
diff --git a/lib/librte_eal/common/include/rte_eal.h b/lib/librte_eal/common/include/rte_eal.h
index abf020b..c8b8800 100644
--- a/lib/librte_eal/common/include/rte_eal.h
+++ b/lib/librte_eal/common/include/rte_eal.h
@@ -43,8 +43,8 @@
 #include <stdint.h>
 #include <sched.h>
 
-#include <rte_per_lcore.h>
 #include <rte_config.h>
+#include <rte_per_lcore.h>
 
 #ifdef __cplusplus
 extern "C" {
diff --git a/lib/librte_eal/linuxapp/eal/eal.c b/lib/librte_eal/linuxapp/eal/eal.c
index 7c78f2d..8dbb819 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -50,9 +50,6 @@
 #include <sys/mman.h>
 #include <sys/queue.h>
 #include <sys/stat.h>
-#if defined(RTE_ARCH_X86)
-#include <sys/io.h>
-#endif
 
 #include <rte_common.h>
 #include <rte_debug.h>
@@ -78,6 +75,9 @@
 #include <rte_version.h>
 #include <rte_atomic.h>
 #include <malloc_heap.h>
+#if defined(RTE_ARCH_X86)
+#include <sys/io.h>
+#endif
 
 #include "eal_private.h"
 #include "eal_thread.h"
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
index fa10329..3359267 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
@@ -41,16 +41,17 @@
 #include <sys/sysmacros.h>
 #include <linux/pci_regs.h>
 
-#if defined(RTE_ARCH_X86)
-#include <sys/io.h>
-#endif
-
+#include <rte_config.h>
 #include <rte_log.h>
 #include <rte_pci.h>
 #include <rte_eal_memconfig.h>
 #include <rte_common.h>
 #include <rte_malloc.h>
 
+#if defined(RTE_ARCH_X86)
+#include <sys/io.h>
+#endif
+
 #include "eal_filesystem.h"
 #include "eal_pci_init.h"
 
diff --git a/lib/librte_eal/linuxapp/eal/meson.build b/lib/librte_eal/linuxapp/eal/meson.build
new file mode 100644
index 0000000..4b5932a
--- /dev/null
+++ b/lib/librte_eal/linuxapp/eal/meson.build
@@ -0,0 +1,57 @@
+local_inc = include_directories('include')
+
+sources = ['eal_alarm.c',
+		'eal_debug.c',
+		'eal_hugepage_info.c',
+		'eal_interrupts.c',
+		'eal_lcore.c',
+		'eal_log.c',
+		'eal_pci_uio.c',
+		'eal_pci_vfio.c',
+		'eal_thread.c',
+		'eal_timer.c',
+		'eal_vfio.c',
+		'eal_vfio_mp_sync.c',
+		'eal.c',
+		'eal_memory.c',
+		'eal_pci.c',
+		'../../common/eal_common_bus.c',
+		'../../common/eal_common_cpuflags.c',
+		'../../common/eal_common_devargs.c',
+		'../../common/eal_common_dev.c',
+		'../../common/eal_common_errno.c',
+		'../../common/eal_common_hexdump.c',
+		'../../common/eal_common_launch.c',
+		'../../common/eal_common_lcore.c',
+		'../../common/eal_common_log.c',
+		'../../common/eal_common_memory.c',
+		'../../common/eal_common_memzone.c',
+		'../../common/eal_common_options.c',
+		'../../common/eal_common_pci.c',
+		'../../common/eal_common_pci_uio.c',
+		'../../common/eal_common_proc.c',
+		'../../common/eal_common_string_fns.c',
+		'../../common/eal_common_tailqs.c',
+		'../../common/eal_common_thread.c',
+		'../../common/eal_common_timer.c',
+		'../../common/eal_common_vdev.c',
+		'../../common/malloc_elem.c',
+		'../../common/malloc_heap.c',
+		'../../common/rte_keepalive.c',
+		'../../common/rte_malloc.c',
+		arch_common
+]
+
+if dpdk_conf.has('LIB_LIBRTE_EAL_XEN_DOM')
+	sources += ['eal_xen_memory.c']
+endif
+
+eal_lib = library('rte_eal', sources,
+			dependencies: dependency('threads'),
+			include_directories : [global_inc, eal_inc, local_inc],
+			c_args: '-D_GNU_SOURCE',
+			link_args: '-ldl',
+			install: true
+)
+
+rte_eal = declare_dependency(link_with: eal_lib, include_directories: [global_inc, eal_inc, local_inc])
diff --git a/lib/librte_eal/linuxapp/meson.build b/lib/librte_eal/linuxapp/meson.build
new file mode 100644
index 0000000..086b27c
--- /dev/null
+++ b/lib/librte_eal/linuxapp/meson.build
@@ -0,0 +1 @@
+subdir('eal')
diff --git a/lib/librte_eal/meson.build b/lib/librte_eal/meson.build
new file mode 100644
index 0000000..7d51d74
--- /dev/null
+++ b/lib/librte_eal/meson.build
@@ -0,0 +1,10 @@
+eal_inc = include_directories('common', 'common/include', 'common/include/arch/@0@'.format(host_machine.cpu_family()))
+
+# build architecture specific code
+subdir('common/arch/@0@'.format(host_machine.cpu_family()))
+
+# build linuxapp or bsdapp code
+subdir('@0@app'.format(host_machine.system().to_lower()))
+
+# add headers to "install" target
+subdir('common/include')
diff --git a/lib/librte_ether/meson.build b/lib/librte_ether/meson.build
new file mode 100644
index 0000000..762316d
--- /dev/null
+++ b/lib/librte_ether/meson.build
@@ -0,0 +1,16 @@
+
+sources = ['rte_ethdev.c', 'rte_flow.c']
+
+install_headers('rte_ethdev.h',
+	'rte_ethdev_pci.h',
+	'rte_ethdev_vdev.h',
+	'rte_eth_ctrl.h',
+	'rte_dev_info.h',
+	'rte_flow.h',
+	'rte_flow_driver.h')
+
+ether_lib = library('rte_ether', sources,
+	dependencies: [rte_eal, rte_ring, rte_mempool, rte_net, rte_mbuf],
+	install: true)
+rte_ether = declare_dependency(link_with: ether_lib,
+	include_directories: include_directories('.'))
diff --git a/lib/librte_hash/meson.build b/lib/librte_hash/meson.build
new file mode 100644
index 0000000..ad7e9b4
--- /dev/null
+++ b/lib/librte_hash/meson.build
@@ -0,0 +1,21 @@
+
+sources = ['rte_cuckoo_hash.c', 'rte_fbk_hash.c']
+
+headers = ['rte_cmp_arm64.h',
+	'rte_cmp_x86.h',
+	'rte_crc_arm64.h',
+	'rte_cuckoo_hash.h',
+	'rte_cuckoo_hash_x86.h',
+	'rte_fbk_hash.h',
+	'rte_hash_crc.h',
+	'rte_hash.h',
+	'rte_jhash.h',
+	'rte_thash.h']
+
+install_headers(headers)
+
+hash_lib = library('rte_hash', sources,
+	dependencies: [rte_eal, rte_ring, rte_compat],
+	install: true)
+rte_hash = declare_dependency(link_with: hash_lib,
+	include_directories: include_directories('.'))
diff --git a/lib/librte_kvargs/meson.build b/lib/librte_kvargs/meson.build
new file mode 100644
index 0000000..f72a1de
--- /dev/null
+++ b/lib/librte_kvargs/meson.build
@@ -0,0 +1,10 @@
+
+sources = ['rte_kvargs.c']
+
+install_headers('rte_kvargs.h')
+
+kvargs_lib = library('rte_kvargs', sources,
+	dependencies: rte_eal,
+	install: true)
+rte_kvargs = declare_dependency(link_with: kvargs_lib,
+	include_directories: include_directories('.'))
diff --git a/lib/librte_mbuf/meson.build b/lib/librte_mbuf/meson.build
new file mode 100644
index 0000000..c8ed03e
--- /dev/null
+++ b/lib/librte_mbuf/meson.build
@@ -0,0 +1,10 @@
+
+sources = ['rte_mbuf.c', 'rte_mbuf_ptype.c']
+
+install_headers('rte_mbuf.h', 'rte_mbuf_ptype.h')
+
+mbuf_lib = library('rte_mbuf', sources,
+	dependencies: [rte_eal, rte_mempool, rte_ring],
+	install: true)
+rte_mbuf = declare_dependency(link_with: mbuf_lib,
+	include_directories: include_directories('.'))
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 1cb0310..d4d803c 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -61,6 +61,7 @@
  */
 
 #include <stdint.h>
+#include <rte_config.h>
 #include <rte_common.h>
 #include <rte_mempool.h>
 #include <rte_memory.h>
diff --git a/lib/librte_mempool/meson.build b/lib/librte_mempool/meson.build
new file mode 100644
index 0000000..1dc37ad
--- /dev/null
+++ b/lib/librte_mempool/meson.build
@@ -0,0 +1,10 @@
+
+sources = ['rte_mempool.c', 'rte_mempool_ops.c']
+
+install_headers('rte_mempool.h')
+
+mempool_lib = library('rte_mempool', sources,
+	dependencies: [rte_eal, rte_ring],
+	install: true)
+rte_mempool = declare_dependency(link_with: mempool_lib,
+	include_directories: include_directories('.'))
diff --git a/lib/librte_metrics/meson.build b/lib/librte_metrics/meson.build
new file mode 100644
index 0000000..f6b5e19
--- /dev/null
+++ b/lib/librte_metrics/meson.build
@@ -0,0 +1,10 @@
+
+sources = ['rte_metrics.c']
+
+install_headers('rte_metrics.h')
+
+metrics_lib = library('rte_metrics', sources,
+	dependencies: rte_eal,
+	install: true)
+rte_metrics = declare_dependency(link_with: metrics_lib,
+	include_directories: include_directories('.'))
diff --git a/lib/librte_net/meson.build b/lib/librte_net/meson.build
new file mode 100644
index 0000000..043a2f2
--- /dev/null
+++ b/lib/librte_net/meson.build
@@ -0,0 +1,19 @@
+
+sources = ['rte_net.c', 'rte_net_crc.c']
+
+install_headers('rte_ip.h',
+	'rte_tcp.h',
+	'rte_udp.h',
+	'rte_sctp.h',
+	'rte_icmp.h',
+	'rte_arp.h',
+	'rte_ether.h',
+	'rte_gre.h',
+	'rte_net.h',
+	'rte_net_crc.h')
+
+net_lib = library('rte_net', sources,
+	dependencies: [rte_eal, rte_mbuf, rte_ring, rte_mempool],
+	install: true)
+rte_net = declare_dependency(link_with: net_lib,
+	include_directories: include_directories('.'))
diff --git a/lib/librte_ring/meson.build b/lib/librte_ring/meson.build
new file mode 100644
index 0000000..d225c09
--- /dev/null
+++ b/lib/librte_ring/meson.build
@@ -0,0 +1,10 @@
+
+sources = ['rte_ring.c']
+
+install_headers('rte_ring.h')
+
+ring_lib = library('rte_ring', sources,
+	dependencies: rte_eal,
+	install: true)
+rte_ring = declare_dependency(link_with: ring_lib,
+	include_directories: include_directories('.'))
diff --git a/lib/meson.build b/lib/meson.build
new file mode 100644
index 0000000..bd60bf2
--- /dev/null
+++ b/lib/meson.build
@@ -0,0 +1,12 @@
+subdir('librte_eal')
+subdir('librte_ring')
+subdir('librte_mempool')
+subdir('librte_acl')
+subdir('librte_cmdline')
+subdir('librte_mbuf')
+subdir('librte_net')
+subdir('librte_ether')
+subdir('librte_compat')
+subdir('librte_hash')
+subdir('librte_kvargs')
+subdir('librte_metrics')
diff --git a/meson.build b/meson.build
new file mode 100644
index 0000000..215ee05
--- /dev/null
+++ b/meson.build
@@ -0,0 +1,70 @@
+project('DPDK', 'C', 
+	version: '17.02.0',
+	license: 'BSD')
+
+error_opts = ['-Wall', '-Wextra', '-Werror', '-Wfatal-errors',
+		'-Wno-unused-result']
+add_project_arguments(error_opts, language: 'c')
+
+optimization_opts = ['-O3']
+add_project_arguments(optimization_opts, language: 'c')
+
+rte_machine = get_option('machine')
+march_opt = '-march=@0@'.format(rte_machine)
+add_project_arguments(march_opt, language: 'c')
+
+global_inc = include_directories('config')
+
+dpdk_conf = configuration_data()
+dpdk_conf.set('RTE_MACHINE', rte_machine)
+if get_option('enable-xen-dom0')
+	dpdk_conf.set('RTE_LIBRTE_XEN_DOM0', 1)
+endif
+
+cc = meson.get_compiler('c')
+compile_time_cpuflags = []
+if (host_machine.cpu_family() == 'x86') or (host_machine.cpu_family() == 'x86_64')
+	dpdk_conf.set('RTE_ARCH_X86', 1)
+	if (host_machine.cpu_family() == 'x86_64')
+		dpdk_conf.set('RTE_ARCH_X86_64', 1)
+		dpdk_conf.set('RTE_ARCH', 'x86_64')
+		dpdk_conf.set('RTE_ARCH_64', 1)
+	else
+		dpdk_conf.set('RTE_ARCH_I686', 1)
+		dpdk_conf.set('RTE_ARCH', 'i686')
+	endif
+
+	if cc.get_define('__SSE4_1__', args: march_opt) != ''
+		dpdk_conf.set('RTE_MACHINE_CPUFLAG_SSE4_1', 1)
+		compile_time_cpuflags += ['RTE_CPUFLAG_SSE4_1']
+	endif
+	if cc.get_define('__SSE4_2__', args: march_opt) != ''
+		dpdk_conf.set('RTE_MACHINE_CPUFLAG_SSE4_2', 1)
+		compile_time_cpuflags += ['RTE_CPUFLAG_SSE4_2']
+	endif
+	if cc.get_define('__AES__', args: march_opt) != ''
+		dpdk_conf.set('RTE_MACHINE_CPUFLAG_AES', 1)
+		compile_time_cpuflags += ['RTE_CPUFLAG_AES']
+	endif
+	if cc.get_define('__PCLMUL__', args: march_opt) != ''
+		dpdk_conf.set('RTE_MACHINE_CPUFLAG_PCLMULQDQ', 1)
+		compile_time_cpuflags += ['RTE_CPUFLAG_PCLMULQDQ']
+	endif
+	if cc.get_define('__AVX__', args: march_opt) != ''
+		dpdk_conf.set('RTE_MACHINE_CPUFLAG_AVX', 1)
+		compile_time_cpuflags += ['RTE_CPUFLAG_AVX']
+	endif
+	if cc.get_define('__AVX2__', args: march_opt) != ''
+		dpdk_conf.set('RTE_MACHINE_CPUFLAG_AVX2', 1)
+		compile_time_cpuflags += ['RTE_CPUFLAG_AVX2']
+	endif
+endif
+dpdk_conf.set('RTE_COMPILE_TIME_CPUFLAGS', ','.join(compile_time_cpuflags))
+
+subdir('lib')
+subdir('drivers')
+subdir('test')
+subdir('app')
+
+# should be last to write out all config values set when parsing other meson files
+subdir('config')
diff --git a/meson_options.txt b/meson_options.txt
new file mode 100644
index 0000000..52d7e54
--- /dev/null
+++ b/meson_options.txt
@@ -0,0 +1,2 @@
+option('enable-xen-dom0', type : 'boolean', value : false, description : 'enable Xen Dom0 Support')
+option('machine', type : 'string', value : 'native', description : 'set the target machine type')
diff --git a/test/meson.build b/test/meson.build
new file mode 100644
index 0000000..a600d0c
--- /dev/null
+++ b/test/meson.build
@@ -0,0 +1 @@
+subdir('test')
diff --git a/test/test/meson.build b/test/test/meson.build
new file mode 100644
index 0000000..cc85408
--- /dev/null
+++ b/test/test/meson.build
@@ -0,0 +1,23 @@
+executable('dpdk-test',
+	sources: [
+		'commands.c',
+		'packet_burst_generator.c',
+		'test.c',
+		'test_acl.c',
+		'test_cmdline.c',
+		'test_cmdline_cirbuf.c',
+		'test_cmdline_etheraddr.c',
+		'test_cmdline_ipaddr.c',
+		'test_cmdline_lib.c',
+		'test_cmdline_num.c',
+		'test_cmdline_portlist.c',
+		'test_cmdline_string.c',
+		'test_cpuflags.c',
+		'test_mp_secondary.c',
+		'test_pmd_perf.c',
+		'test_ring.c',
+		'test_ring_perf.c'
+	],
+	dependencies: [rte_eal, rte_ring, rte_mempool, rte_cmdline,
+		rte_mbuf, rte_net, rte_ether, rte_acl],
+	install: true)
diff --git a/test/test/test.c b/test/test/test.c
index c561eb5..671d915 100644
--- a/test/test/test.c
+++ b/test/test/test.c
@@ -41,14 +41,7 @@
 #include <ctype.h>
 #include <sys/queue.h>
 
-#ifdef RTE_LIBRTE_CMDLINE
-#include <cmdline_rdline.h>
-#include <cmdline_parse.h>
-#include <cmdline_socket.h>
-#include <cmdline.h>
-extern cmdline_parse_ctx_t main_ctx[];
-#endif
-
+#include <rte_config.h>
 #include <rte_memory.h>
 #include <rte_memzone.h>
 #include <rte_eal.h>
@@ -58,6 +51,14 @@ extern cmdline_parse_ctx_t main_ctx[];
 #ifdef RTE_LIBRTE_TIMER
 #include <rte_timer.h>
 #endif
+#ifdef RTE_LIBRTE_CMDLINE
+#include <cmdline_rdline.h>
+#include <cmdline_parse.h>
+#include <cmdline_socket.h>
+#include <cmdline.h>
+extern cmdline_parse_ctx_t main_ctx[];
+#endif
+
 
 #include "test.h"
 
-- 
2.9.4

Re: [dpdk-dev] [dpdk-dev,RFC] build for DPDK with meson and ninja

[Ilya Maximets]

Hi, Bruce.

That's interesting approach. I tried this on my system and it works.
I also tried to do some modifications to add conditional support for
libnuma in rte_eal to build with my patches applied. It looks promising.
That is what I've got:

-------------------------------------------------------------------------
--- a/lib/librte_eal/linuxapp/eal/meson.build
+++ b/lib/librte_eal/linuxapp/eal/meson.build
@@ -46,8 +46,12 @@ if dpdk_conf.has('LIB_LIBRTE_EAL_XEN_DOM')
 	sources += ['eal_xen_memory.c']
 endif
 
+cc = meson.get_compiler('c')
+libnuma = cc.find_library('numa', required: false)
+dpdk_conf.set10('RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES', libnuma.found())
+
 eal_lib = library('rte_eal', sources,
-			dependencies: dependency('threads'),
+			dependencies: [dependency('threads'), libnuma],
 			include_directories : [global_inc, eal_inc, local_inc],
 			c_args: '-D_GNU_SOURCE',
 			link_args: '-ldl',
-------------------------------------------------------------------------

Result:
	Library numa found: YES
	and
	#define RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES 1
	(NO and 0 respectively with wrong library)

	Build works. I didn't try to install the binaries.

One found issue is that where is no 'meson' package in RHEL 7.
I checked build using meson from git.

Best regards, Ilya Maximets.

Re: [dpdk-dev] [dpdk-dev,RFC] build for DPDK with meson and ninja

[Bruce Richardson]

On Wed, Jun 07, 2017 at 05:36:41PM +0300, Ilya Maximets wrote:
> Hi, Bruce.
> 
> That's interesting approach. I tried this on my system and it works.
> I also tried to do some modifications to add conditional support for
> libnuma in rte_eal to build with my patches applied. It looks promising.
> That is what I've got:
> 
> -------------------------------------------------------------------------
> --- a/lib/librte_eal/linuxapp/eal/meson.build
> +++ b/lib/librte_eal/linuxapp/eal/meson.build
> @@ -46,8 +46,12 @@ if dpdk_conf.has('LIB_LIBRTE_EAL_XEN_DOM')
>  	sources += ['eal_xen_memory.c']
>  endif
>  
> +cc = meson.get_compiler('c')
> +libnuma = cc.find_library('numa', required: false)
> +dpdk_conf.set10('RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES', libnuma.found())
> +
>  eal_lib = library('rte_eal', sources,
> -			dependencies: dependency('threads'),
> +			dependencies: [dependency('threads'), libnuma],
>  			include_directories : [global_inc, eal_inc, local_inc],
>  			c_args: '-D_GNU_SOURCE',
>  			link_args: '-ldl',
> -------------------------------------------------------------------------
> 
> Result:
> 	Library numa found: YES
> 	and
> 	#define RTE_LIBRTE_EAL_NUMA_AWARE_HUGEPAGES 1
> 	(NO and 0 respectively with wrong library)
> 
> 	Build works. I didn't try to install the binaries.
>
Great. Glad to see it works out that simply for you!

> One found issue is that where is no 'meson' package in RHEL 7.  I
> checked build using meson from git.
> 
> Best regards, Ilya Maximets.
> 
Ok, thanks for reporting. I haven't investigated the distro support for
meson yet, other than having it on Fedora and debian, which i use, but
you can also get it easily using "pip3" for python3 - on Fedora this is
in "python3-pip" package - with the cmd: "pip3 install meson".

Regards,
/Bruce

Re: [dpdk-dev] [RFC PATCH] build for DPDK with meson and ninja

[Jerin Jacob]

-----Original Message-----
> Date: Wed, 7 Jun 2017 11:47:43 +0100
> From: Bruce Richardson <bruce.richardson@intel.com>
> To: dev@dpdk.org
> CC: Bruce Richardson <bruce.richardson@intel.com>
> Subject: [dpdk-dev] [RFC PATCH] build for DPDK with meson and ninja
> X-Mailer: git-send-email 2.9.4
> 
> to use, need to have meson >= 0.4 and ninja-build packages installed.
> 
> Then do the following in main DPDK directory:
> 
> meson build
> cd build
> ninja
> sudo ninja install

Tested on Archlinux + ccache + gcc7.

Impressive. Build is really quick. Especially in empty build case, where
existing build system takes a while to complete. Thanks for the RFC.

Faced an issue(The latest gcc 7 specific DPDK flags are not showing
up correctly) with ccache + gcc 7 environment with ninja.
Look like something is missing in configuration side.

Re: [dpdk-dev] [RFC PATCH] build for DPDK with meson and ninja

[Bruce Richardson]

On Wed, Jun 07, 2017 at 11:42:59PM +0530, Jerin Jacob wrote:
> -----Original Message-----
> > Date: Wed, 7 Jun 2017 11:47:43 +0100
> > From: Bruce Richardson <bruce.richardson@intel.com>
> > To: dev@dpdk.org
> > CC: Bruce Richardson <bruce.richardson@intel.com>
> > Subject: [dpdk-dev] [RFC PATCH] build for DPDK with meson and ninja
> > X-Mailer: git-send-email 2.9.4
> > 
> > to use, need to have meson >= 0.4 and ninja-build packages installed.
> > 
> > Then do the following in main DPDK directory:
> > 
> > meson build
> > cd build
> > ninja
> > sudo ninja install
> 
> Tested on Archlinux + ccache + gcc7.
> 
> Impressive. Build is really quick. Especially in empty build case, where
> existing build system takes a while to complete. Thanks for the RFC.

Thanks for testing. That's what I saw too, and it's a really nice
benefit.
> 
> Faced an issue(The latest gcc 7 specific DPDK flags are not showing
> up correctly) with ccache + gcc 7 environment with ninja.
> Look like something is missing in configuration side.
Highly likely. I didn't explicitly port over all our cflags that are
being specified in the makefiles, just enough to get it to compile on my
system. I didn't have enough time on this to cover as many things as I
would like.

/Bruce

Re: [dpdk-dev] [RFC PATCH] build for DPDK with meson and ninja

[Shreyansh Jain]

Hello Bruce,

On Wednesday 07 June 2017 04:17 PM, Bruce Richardson wrote:
> to use, need to have meson >= 0.4 and ninja-build packages installed.
> 
> Then do the following in main DPDK directory:
> 
> meson build
> cd build
> ninja
> sudo ninja install
> 
> This will compile up some DPDK libs, the FVL PMD and testpmd and install
> them in /usr/local/. [On Fedora you will need to add /usr/local/lib64 to
> your ld path, it's not there by default.]
> Then you can run testpmd as e.g.
> 

<...snip...>

> diff --git a/test/test/meson.build b/test/test/meson.build
> new file mode 100644
> index 0000000..cc85408
> --- /dev/null
> +++ b/test/test/meson.build
> @@ -0,0 +1,23 @@
> +executable('dpdk-test',
> +	sources: [
> +		'commands.c',
> +		'packet_burst_generator.c',
> +		'test.c',
> +		'test_acl.c',
> +		'test_cmdline.c',
> +		'test_cmdline_cirbuf.c',
> +		'test_cmdline_etheraddr.c',
> +		'test_cmdline_ipaddr.c',
> +		'test_cmdline_lib.c',
> +		'test_cmdline_num.c',
> +		'test_cmdline_portlist.c',
> +		'test_cmdline_string.c',
> +		'test_cpuflags.c',
> +		'test_mp_secondary.c',
> +		'test_pmd_perf.c',
> +		'test_ring.c',
> +		'test_ring_perf.c'
> +	],
> +	dependencies: [rte_eal, rte_ring, rte_mempool, rte_cmdline,
> +		rte_mbuf, rte_net, rte_ether, rte_acl],
> +	install: true)

<..snip..>

I tried this with x86 and it worked like a charm. Really nice and clean
way to build DPDK - and super fast. Awesome.

I want to use this for an ARM target. Any idea what I should change in
meson.build? Or, is that even straightforward?
(Yes, I can lookup documentation for meson - just being lazy. If you
don't have much idea, I will give this a spin on ARM in a couple of
days)

-
Shreyansh

Re: [dpdk-dev] [RFC PATCH] build for DPDK with meson and ninja

[Bruce Richardson]

On Thu, Jun 08, 2017 at 12:50:38PM +0530, Shreyansh Jain wrote:
> Hello Bruce,
> 
> On Wednesday 07 June 2017 04:17 PM, Bruce Richardson wrote:
> > to use, need to have meson >= 0.4 and ninja-build packages installed.
> > 
> > Then do the following in main DPDK directory:
> > 
> > meson build
> > cd build
> > ninja
> > sudo ninja install
> > 
> > This will compile up some DPDK libs, the FVL PMD and testpmd and install
> > them in /usr/local/. [On Fedora you will need to add /usr/local/lib64 to
> > your ld path, it's not there by default.]
> > Then you can run testpmd as e.g.
> > 
> 
> <...snip...>
> 
> > diff --git a/test/test/meson.build b/test/test/meson.build
> > new file mode 100644
> > index 0000000..cc85408
> > --- /dev/null
> > +++ b/test/test/meson.build
> > @@ -0,0 +1,23 @@
> > +executable('dpdk-test',
> > +	sources: [
> > +		'commands.c',
> > +		'packet_burst_generator.c',
> > +		'test.c',
> > +		'test_acl.c',
> > +		'test_cmdline.c',
> > +		'test_cmdline_cirbuf.c',
> > +		'test_cmdline_etheraddr.c',
> > +		'test_cmdline_ipaddr.c',
> > +		'test_cmdline_lib.c',
> > +		'test_cmdline_num.c',
> > +		'test_cmdline_portlist.c',
> > +		'test_cmdline_string.c',
> > +		'test_cpuflags.c',
> > +		'test_mp_secondary.c',
> > +		'test_pmd_perf.c',
> > +		'test_ring.c',
> > +		'test_ring_perf.c'
> > +	],
> > +	dependencies: [rte_eal, rte_ring, rte_mempool, rte_cmdline,
> > +		rte_mbuf, rte_net, rte_ether, rte_acl],
> > +	install: true)
> 
> <..snip..>
> 
> I tried this with x86 and it worked like a charm. Really nice and clean
> way to build DPDK - and super fast. Awesome.
> 
> I want to use this for an ARM target. Any idea what I should change in
> meson.build? Or, is that even straightforward?
> (Yes, I can lookup documentation for meson - just being lazy. If you
> don't have much idea, I will give this a spin on ARM in a couple of
> days)
> 
I haven't looked to see how to get it to work on arm - I just wanted to
get some sort of prototype out and get feedback before I invested too
much extra time into this. :-) I suggest to start by checking what the
"host_machine" structure reports for your arm targets and work from
there. See librte_eal/common/include/meson.build:

subdir('arch/@0@'.format(host_machine.cpu_family()))

I also was learning meson on-the-fly while working on this, so I'm by no
means an expert.

/Bruce

Re: [dpdk-dev] [RFC PATCH] replace DPDK config and build system

[Van Haaren, Harry]

> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson
> Sent: Wednesday, June 7, 2017 11:48 AM
> To: dev@dpdk.org
> Cc: Richardson, Bruce <bruce.richardson@intel.com>
> Subject: [dpdk-dev] [RFC PATCH] replace DPDK config and build system
> 
> Hi all,
> 
> following on from the pressing need to add support in DPDK for detecting
> and managing external dependencies, I undertook to see what options we had.
> However, unrelated to this, over time, I have become increasingly
> frustrated by the complexity of the DPDK configuration and build system. As
> such, I feel that looking at some of the newer build tools that are out
> there might give us the additional functionality we want, along with other
> benefits. As such, I undertook a prototype using "meson"[1] for
> configuration, which uses "ninja" as a backend for doing the actual build.
> 
> With these tools we get the following benefits (not a complete list):
> * support for detecting dependencies on the system
> * support for detecting compiler features, including functions, defines
> * improved maintainability through a high-level language, which gives
>   decent error messages including line numbers (!!)
> * co-existence with the existing makefile system without making any changes
>   to it
> * faster builds using ninja - on my many-core system, the builds seem
>   significantly faster than with our existing system. Especially in the
>   nothing-has-changed case, builds with my prototype return instantly,
>   compared to taking a few seconds to recursively check each directory with
>   the current build system
> * the ability to switch to using a standard "ninja" + "ninja install" setup
> * the chance to rework our existing build-config files, and hopefully
>   pretty much remove them.
> * pkg-config support.
> * we get to move away from our bespoke build system
> * dependencies in each lib can be moved back to being tracked in the libs
>   files themselves, not up a level
> 
> 
> Of course, it's not a panacea, but having spent hours on the prototype thus
> far, I find working with meson and ninja far more user-friendly than
> working on our makefiles, and again the build speed is a really nice
> improvment too.
> 
> The prototype is incomplete, but it does build a reasonable number of our
> libraries, some unit tests, the i40e PMD and the testpmd binary, and I have
> successfully passed traffic using testpmd from the build. Some things are
> not fully correct, e.g. static builds aren't working right now, as I haven't
> correctly done all the dependency tracking, I think, and the cpu flag
> detection has issues. It also has only been tried on x86_64 linux, on a
> couple of systems, so YMMV. However, I feel it's a reasonable enough start
> point to show what we might be able to achieve.
> 
> Please take the prototype and test it out. I think it's a better
> alternative to trying to bolt on additional functionality to our existing
> config and build system.


Test drive done; here are my experiences / thoughts:

1) Understanding the Meson build files is much easier for me than the current build-files. I'll admit that bash scripting is not my forte, with the caveat that if my basic bash scripting doesn't suffice, others in the community are probably in a similar position.

2) I see huge value in pkg-config integration - linking made easy. From a developer usability POV, a project should provide a pkg-config file, and configure itself based on the pkg-config files available on the system. 

3) The speed of ninja is impressive - particularly in the small-amounts-of-work case. Try it on your own machine if you don't believe me :)

4) "build variants" are super easy, meson build && meson build_variant  will create two directories, with .o files contained under it (same as one possible usage of the current system - just calling out that that feature remains).

5) Vim users, there is a "mesonic" plugin[1] which provides syntax highlighting for Meson files, the Meson Options file, and Meson integration to the Vim compiler hooks. Aka typing  :make   will cause Ninja to be invoked and compile. There are more fancy features, check the script page.

6) Ninja uninstall will reverse a previous installation, and returns a clean system. Nice for testing and integrating DPDK with applications that expect DPDK to be installed system-wide.


Of course no build system is perfect - and I'd guess Meson also has a few gritty details that are not ideal - but to me this test-drive has shown promise. Opinions from non-developers may be of particular interest..

@DPDK Packagers, do you have experience with Meson? Does it integrate well with (your) existing infrastructure? Hope you don't mind me adding you to CC :)

-Harry

[1] http://www.vim.org/scripts/script.php?script_id=5378

Re: [dpdk-dev] [RFC PATCH] replace DPDK config and build system

[Bruce Richardson]

On Wed, Jun 07, 2017 at 02:23:04PM +0100, Luca Boccassi wrote:
> On Wed, 2017-06-07 at 13:08 +0000, Van Haaren, Harry wrote:
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce
> > > Richardson
> > > Sent: Wednesday, June 7, 2017 11:48 AM
> > > To: dev@dpdk.org
> > > Cc: Richardson, Bruce <bruce.richardson@intel.com>
> > > Subject: [dpdk-dev] [RFC PATCH] replace DPDK config and build
> > > system
> > > 
> > > Hi all,
> > > 
> > > following on from the pressing need to add support in DPDK for
> > > detecting
> > > and managing external dependencies, I undertook to see what options
> > > we had.
> > > However, unrelated to this, over time, I have become increasingly
> > > frustrated by the complexity of the DPDK configuration and build
> > > system. As
> > > such, I feel that looking at some of the newer build tools that are
> > > out
> > > there might give us the additional functionality we want, along
> > > with other
> > > benefits. As such, I undertook a prototype using "meson"[1] for
> > > configuration, which uses "ninja" as a backend for doing the actual
> > > build.
> > > 
> > > With these tools we get the following benefits (not a complete
> > > list):
> > > * support for detecting dependencies on the system
> > > * support for detecting compiler features, including functions,
> > > defines
> > > * improved maintainability through a high-level language, which
> > > gives
> > >   decent error messages including line numbers (!!)
> > > * co-existence with the existing makefile system without making any
> > > changes
> > >   to it
> > > * faster builds using ninja - on my many-core system, the builds
> > > seem
> > >   significantly faster than with our existing system. Especially in
> > > the
> > >   nothing-has-changed case, builds with my prototype return
> > > instantly,
> > >   compared to taking a few seconds to recursively check each
> > > directory with
> > >   the current build system
> > > * the ability to switch to using a standard "ninja" + "ninja
> > > install" setup
> > > * the chance to rework our existing build-config files, and
> > > hopefully
> > >   pretty much remove them.
> > > * pkg-config support.
> > > * we get to move away from our bespoke build system
> > > * dependencies in each lib can be moved back to being tracked in
> > > the libs
> > >   files themselves, not up a level
> > > 
> > > 
> > > Of course, it's not a panacea, but having spent hours on the
> > > prototype thus
> > > far, I find working with meson and ninja far more user-friendly
> > > than
> > > working on our makefiles, and again the build speed is a really
> > > nice
> > > improvment too.
> > > 
> > > The prototype is incomplete, but it does build a reasonable number
> > > of our
> > > libraries, some unit tests, the i40e PMD and the testpmd binary,
> > > and I have
> > > successfully passed traffic using testpmd from the build. Some
> > > things are
> > > not fully correct, e.g. static builds aren't working right now, as
> > > I haven't
> > > correctly done all the dependency tracking, I think, and the cpu
> > > flag
> > > detection has issues. It also has only been tried on x86_64 linux,
> > > on a
> > > couple of systems, so YMMV. However, I feel it's a reasonable
> > > enough start
> > > point to show what we might be able to achieve.
> > > 
> > > Please take the prototype and test it out. I think it's a better
> > > alternative to trying to bolt on additional functionality to our
> > > existing
> > > config and build system.
> > 
> > 
> > Test drive done; here are my experiences / thoughts:
> > 
> > 1) Understanding the Meson build files is much easier for me than the
> > current build-files. I'll admit that bash scripting is not my forte,
> > with the caveat that if my basic bash scripting doesn't suffice,
> > others in the community are probably in a similar position.
> > 
> > 2) I see huge value in pkg-config integration - linking made easy.
> > From a developer usability POV, a project should provide a pkg-config 
> > file, and configure itself based on the pkg-config files available on
> > the system. 
> > 
> > 3) The speed of ninja is impressive - particularly in the small-
> > amounts-of-work case. Try it on your own machine if you don't believe
> > me :)
> > 
> > 4) "build variants" are super easy, meson build && meson
> > build_variant  will create two directories, with .o files contained
> > under it (same as one possible usage of the current system - just
> > calling out that that feature remains).
> > 
> > 5) Vim users, there is a "mesonic" plugin[1] which provides syntax
> > highlighting for Meson files, the Meson Options file, and Meson
> > integration to the Vim compiler hooks. Aka typing  :make   will cause
> > Ninja to be invoked and compile. There are more fancy features, check
> > the script page.
> > 
> > 6) Ninja uninstall will reverse a previous installation, and returns
> > a clean system. Nice for testing and integrating DPDK with
> > applications that expect DPDK to be installed system-wide.
> > 
> > 
> > Of course no build system is perfect - and I'd guess Meson also has a
> > few gritty details that are not ideal - but to me this test-drive has
> > shown promise. Opinions from non-developers may be of particular
> > interest..
> > 
> > @DPDK Packagers, do you have experience with Meson? Does it integrate
> > well with (your) existing infrastructure? Hope you don't mind me
> > adding you to CC :)
> 
> While I do not have personal experience with it, I know that recently
> the Debian/Ubuntu tools have gained support for meson+ninja (debhelper
> version 10.3), so it should not be a problem for myself and Christian.
> 
> In fact, I personally think it's a big and very welcome improvement, so
> thank you Bruce for this work!
> 
> I will try to find time soon to test this patch in the context of
> packaging the libraries.
>

Great, thanks for taking a look at it. Please note that this does
require meson 0.4 right now, because we do so much stuff with optimizing
for instruction sets we really need the new "has_define()" function that
comes only in meson 0.4. However, I anticipate that given the time it is
likely to take to get anything like this into DPDK, meson 0.4 should be
pretty widespread by then. :-)

/Bruce

Re: [dpdk-dev] [RFC PATCH] replace DPDK config and build system

[Stephen Hemminger]

On Wed,  7 Jun 2017 11:47:42 +0100
Bruce Richardson <bruce.richardson@intel.com> wrote:

> The prototype is incomplete, but it does build a reasonable number of our
> libraries, some unit tests, the i40e PMD and the testpmd binary, and I have
> successfully passed traffic using testpmd from the build. Some things are
> not fully correct, e.g. static builds aren't working right now, as I haven't
> correctly done all the dependency tracking, I think, and the cpu flag
> detection has issues. It also has only been tried on x86_64 linux, on a
> couple of systems, so YMMV. However, I feel it's a reasonable enough start
> point to show what we might be able to achieve.

Remember that in many cases the build system and the target system are different.
One of the problems with previous DPDK builds where build system was on bare metal
but deployment target was on a more limited VM environment. I sweated through
lots of  pain on that.

Re: [dpdk-dev] [RFC PATCH] replace DPDK config and build system

[Bruce Richardson]

On Wed, Jun 07, 2017 at 04:26:17PM -0700, Stephen Hemminger wrote:
> On Wed,  7 Jun 2017 11:47:42 +0100
> Bruce Richardson <bruce.richardson@intel.com> wrote:
> 
> > The prototype is incomplete, but it does build a reasonable number of our
> > libraries, some unit tests, the i40e PMD and the testpmd binary, and I have
> > successfully passed traffic using testpmd from the build. Some things are
> > not fully correct, e.g. static builds aren't working right now, as I haven't
> > correctly done all the dependency tracking, I think, and the cpu flag
> > detection has issues. It also has only been tried on x86_64 linux, on a
> > couple of systems, so YMMV. However, I feel it's a reasonable enough start
> > point to show what we might be able to achieve.
> 
> Remember that in many cases the build system and the target system are different.
> One of the problems with previous DPDK builds where build system was on bare metal
> but deployment target was on a more limited VM environment. I sweated through
> lots of  pain on that.

Yep, and I'm not going to claim that this is going to solve world hunger
here :-) or that switching is going to be easy. However, talking of
building and deploying on different targets, meson is designed to allow
cross-compilation, see for example the built-in objects for
"build_machine", "host_machine" and "target_machine":
http://mesonbuild.com/Reference-manual.html#build_machine-object

Also, one thing I did add into this prototype was some build argument
support to test how that would work. By default, when you run meson, it
will set up the cflags to pass in -march=native, much as is done by our
default targets now. However, this is easily changed when doing your own
builds, for example, to do two different builds in different directories:

$ meson native_build
...
Checking for value of define "__PCLMUL__": 1
Checking for value of define "__AVX__": 1
Checking for value of define "__AVX2__": 1
...

$ meson -Dmachine=ivybridge ivybridge_build
...
Checking for value of define "__PCLMUL__": 1
Checking for value of define "__AVX__": 1
Checking for value of define "__AVX2__":
...

This way you can easily set up different builds for different machine
targets, with different instruction set levels, as seen from where the
second case above did not report AVX2 support. The project-specific
options are given in meson_options.txt. See also relevant section in
meson docs: http://mesonbuild.com/Build-options.html

Regards,
/Bruce

Re: [dpdk-dev] [RFC PATCH] replace DPDK config and build system

[Stephen Hemminger]

On Thu, 8 Jun 2017 09:59:01 +0100
Bruce Richardson <bruce.richardson@intel.com> wrote:

> On Wed, Jun 07, 2017 at 04:26:17PM -0700, Stephen Hemminger wrote:
> > On Wed,  7 Jun 2017 11:47:42 +0100
> > Bruce Richardson <bruce.richardson@intel.com> wrote:
> >   
> > > The prototype is incomplete, but it does build a reasonable number of our
> > > libraries, some unit tests, the i40e PMD and the testpmd binary, and I have
> > > successfully passed traffic using testpmd from the build. Some things are
> > > not fully correct, e.g. static builds aren't working right now, as I haven't
> > > correctly done all the dependency tracking, I think, and the cpu flag
> > > detection has issues. It also has only been tried on x86_64 linux, on a
> > > couple of systems, so YMMV. However, I feel it's a reasonable enough start
> > > point to show what we might be able to achieve.  
> > 
> > Remember that in many cases the build system and the target system are different.
> > One of the problems with previous DPDK builds where build system was on bare metal
> > but deployment target was on a more limited VM environment. I sweated through
> > lots of  pain on that.  
> 
> Yep, and I'm not going to claim that this is going to solve world hunger
> here :-) or that switching is going to be easy. However, talking of
> building and deploying on different targets, meson is designed to allow
> cross-compilation, see for example the built-in objects for
> "build_machine", "host_machine" and "target_machine":
> http://mesonbuild.com/Reference-manual.html#build_machine-object
> 
> Also, one thing I did add into this prototype was some build argument
> support to test how that would work. By default, when you run meson, it
> will set up the cflags to pass in -march=native, much as is done by our
> default targets now. However, this is easily changed when doing your own
> builds, for example, to do two different builds in different directories:
> 
> $ meson native_build
> ...
> Checking for value of define "__PCLMUL__": 1
> Checking for value of define "__AVX__": 1
> Checking for value of define "__AVX2__": 1
> ...
> 
> $ meson -Dmachine=ivybridge ivybridge_build
> ...
> Checking for value of define "__PCLMUL__": 1
> Checking for value of define "__AVX__": 1
> Checking for value of define "__AVX2__":
> ...
> 
> This way you can easily set up different builds for different machine
> targets, with different instruction set levels, as seen from where the
> second case above did not report AVX2 support. The project-specific
> options are given in meson_options.txt. See also relevant section in
> meson docs: http://mesonbuild.com/Build-options.html
> 
> Regards,
> /Bruce

On a side note, it would be good to use the GCC extensions that allow
building different versions of the same routine into one binary.

Re: [dpdk-dev] [RFC PATCH] replace DPDK config and build system

[Christian Ehrhardt]

On Thu, Jun 8, 2017 at 10:26 AM, Stephen Hemminger <
stephen@networkplumber.org> wrote:

> On a side note, it would be good to use the GCC extensions that allow
> building different versions of the same routine into one binary.
>

And we are back to the discussion we had two years ago about how to deliver
generic yet also optimized binaries in one shot.
But if the new build system can enable us to do so I'm all in for that.

Thanks for bringing this up in that context Stephen - might be just the
right time to look at it again.



-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Re: [dpdk-dev] [RFC PATCH] replace DPDK config and build system

[Wiles, Keith]

> On Jun 8, 2017, at 1:07 PM, Christian Ehrhardt <christian.ehrhardt@canonical.com> wrote:
> 
> On Thu, Jun 8, 2017 at 10:26 AM, Stephen Hemminger <
> stephen@networkplumber.org> wrote:
> 
>> On a side note, it would be good to use the GCC extensions that allow
>> building different versions of the same routine into one binary.
>> 
> 
> And we are back to the discussion we had two years ago about how to deliver
> generic yet also optimized binaries in one shot.
> But if the new build system can enable us to do so I'm all in for that.
> 
> Thanks for bringing this up in that context Stephen - might be just the
> right time to look at it again.

I agree we need to look into supporting this feature, but I think we need to get the new build system (if we are going to adopt it) to parity to our current build system first.

We need to make sure we can build on the different distro as I ran into version issues with Ninja and Meson using Ubuntu 17.04. I had to upgrade Meson to latest, which was not in 17.04 release :-(

I think Bruce touched on this issue around eliminating or reducing greatly the number of configuration options in our config file today.

> 
> 
> 
> -- 
> Christian Ehrhardt
> Software Engineer, Ubuntu Server
> Canonical Ltd

Regards,
Keith

Re: [dpdk-dev] [RFC PATCH] replace DPDK config and build system

[Bruce Richardson]

On Thu, Jun 08, 2017 at 12:07:05PM -0600, Christian Ehrhardt wrote:
> On Thu, Jun 8, 2017 at 10:26 AM, Stephen Hemminger <
> stephen@networkplumber.org> wrote:
> 
> > On a side note, it would be good to use the GCC extensions that allow
> > building different versions of the same routine into one binary.
> >
> 
> And we are back to the discussion we had two years ago about how to deliver
> generic yet also optimized binaries in one shot.
> But if the new build system can enable us to do so I'm all in for that.
> 
> Thanks for bringing this up in that context Stephen - might be just the
> right time to look at it again.
> 
Yep, we can do that. First though, we need to decide what our minimum
supported compiler baseline is going to be.
Also, if the replace the build system, do we want to do a complete
on-shot replacement, or do we want to keep the older one around in
parallel for a while e.g. to support older OS's and compilers.

/Bruce

Re: [dpdk-dev] [RFC PATCH] replace DPDK config and build system

[Wiles, Keith]

> On Jun 9, 2017, at 4:05 AM, Bruce Richardson <bruce.richardson@intel.com> wrote:
> 
> On Thu, Jun 08, 2017 at 12:07:05PM -0600, Christian Ehrhardt wrote:
>> On Thu, Jun 8, 2017 at 10:26 AM, Stephen Hemminger <
>> stephen@networkplumber.org> wrote:
>> 
>>> On a side note, it would be good to use the GCC extensions that allow
>>> building different versions of the same routine into one binary.
>>> 
>> 
>> And we are back to the discussion we had two years ago about how to deliver
>> generic yet also optimized binaries in one shot.
>> But if the new build system can enable us to do so I'm all in for that.
>> 
>> Thanks for bringing this up in that context Stephen - might be just the
>> right time to look at it again.
>> 
> Yep, we can do that. First though, we need to decide what our minimum
> supported compiler baseline is going to be.
> Also, if the replace the build system, do we want to do a complete
> on-shot replacement, or do we want to keep the older one around in
> parallel for a while e.g. to support older OS's and compilers.

I think it would be a good idea to keep the old version for now.

I would suggest adding the new build system to a sandbox repo until we think we have parity then merge into main. Keep the old system in place to allow for other systems until we believe we really have covered all of the bases.

What would your baseline be ?

I would suggest pick a few distros like Linux Ubuntu, Fedora, Red Hat just a guess at the ones we need to support first.

Think we have to support IA and ARM at the same time for the few distros we start with first or at least pick the most used one for ARM first. 

> 
> /Bruce

Regards,
Keith

Re: [dpdk-dev] [RFC PATCH] replace DPDK config and build system

[Morten Brørup]

FYI: We are using Crosstool-NG (http://crosstool-ng.github.io/). It seems to be quite popular for cross compiling.


Med venlig hilsen / kind regards
- Morten Brørup

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wiles, Keith
> Sent: Friday, June 9, 2017 8:06 PM
> To: Richardson, Bruce
> Cc: Christian Ehrhardt; Stephen Hemminger; dev
> Subject: Re: [dpdk-dev] [RFC PATCH] replace DPDK config and build
> system
> 
> 
> > On Jun 9, 2017, at 4:05 AM, Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> >
> > On Thu, Jun 08, 2017 at 12:07:05PM -0600, Christian Ehrhardt wrote:
> >> On Thu, Jun 8, 2017 at 10:26 AM, Stephen Hemminger <
> >> stephen@networkplumber.org> wrote:
> >>
> >>> On a side note, it would be good to use the GCC extensions that
> >>> allow building different versions of the same routine into one
> binary.
> >>>
> >>
> >> And we are back to the discussion we had two years ago about how to
> >> deliver generic yet also optimized binaries in one shot.
> >> But if the new build system can enable us to do so I'm all in for
> that.
> >>
> >> Thanks for bringing this up in that context Stephen - might be just
> >> the right time to look at it again.
> >>
> > Yep, we can do that. First though, we need to decide what our minimum
> > supported compiler baseline is going to be.
> > Also, if the replace the build system, do we want to do a complete
> > on-shot replacement, or do we want to keep the older one around in
> > parallel for a while e.g. to support older OS's and compilers.
> 
> I think it would be a good idea to keep the old version for now.
> 
> I would suggest adding the new build system to a sandbox repo until we
> think we have parity then merge into main. Keep the old system in place
> to allow for other systems until we believe we really have covered all
> of the bases.
> 
> What would your baseline be ?
> 
> I would suggest pick a few distros like Linux Ubuntu, Fedora, Red Hat
> just a guess at the ones we need to support first.
> 
> Think we have to support IA and ARM at the same time for the few
> distros we start with first or at least pick the most used one for ARM
> first.
> 
> >
> > /Bruce
> 
> Regards,
> Keith
> 

Re: [dpdk-dev] [RFC PATCH] replace DPDK config and build system

[Bruce Richardson]

On Tue, Jun 20, 2017 at 03:34:58PM +0200, Morten Brørup wrote:
> FYI: We are using Crosstool-NG (http://crosstool-ng.github.io/). It seems to be quite popular for cross compiling.
> 

How does a tool like that interact with build-systems then - either with
our current one, or with a hypothetical future one using meson+ninja as
below? Does it simplify what needs to be provided in the build config
tool?

/Bruce

> 
> Med venlig hilsen / kind regards
> - Morten Brørup
> 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wiles, Keith
> > Sent: Friday, June 9, 2017 8:06 PM
> > To: Richardson, Bruce
> > Cc: Christian Ehrhardt; Stephen Hemminger; dev
> > Subject: Re: [dpdk-dev] [RFC PATCH] replace DPDK config and build
> > system
> > 
> > 
> > > On Jun 9, 2017, at 4:05 AM, Bruce Richardson
> > <bruce.richardson@intel.com> wrote:
> > >
> > > On Thu, Jun 08, 2017 at 12:07:05PM -0600, Christian Ehrhardt wrote:
> > >> On Thu, Jun 8, 2017 at 10:26 AM, Stephen Hemminger <
> > >> stephen@networkplumber.org> wrote:
> > >>
> > >>> On a side note, it would be good to use the GCC extensions that
> > >>> allow building different versions of the same routine into one
> > binary.
> > >>>
> > >>
> > >> And we are back to the discussion we had two years ago about how to
> > >> deliver generic yet also optimized binaries in one shot.
> > >> But if the new build system can enable us to do so I'm all in for
> > that.
> > >>
> > >> Thanks for bringing this up in that context Stephen - might be just
> > >> the right time to look at it again.
> > >>
> > > Yep, we can do that. First though, we need to decide what our minimum
> > > supported compiler baseline is going to be.
> > > Also, if the replace the build system, do we want to do a complete
> > > on-shot replacement, or do we want to keep the older one around in
> > > parallel for a while e.g. to support older OS's and compilers.
> > 
> > I think it would be a good idea to keep the old version for now.
> > 
> > I would suggest adding the new build system to a sandbox repo until we
> > think we have parity then merge into main. Keep the old system in place
> > to allow for other systems until we believe we really have covered all
> > of the bases.
> > 
> > What would your baseline be ?
> > 
> > I would suggest pick a few distros like Linux Ubuntu, Fedora, Red Hat
> > just a guess at the ones we need to support first.
> > 
> > Think we have to support IA and ARM at the same time for the few
> > distros we start with first or at least pick the most used one for ARM
> > first.
> > 
> > >
> > > /Bruce
> > 
> > Regards,
> > Keith
> > 
> 

Re: [dpdk-dev] [RFC PATCH] replace DPDK config and build system

[Morten Brørup]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson
> Sent: Tuesday, June 20, 2017 3:41 PM
> To: Morten Brørup
> Cc: Wiles, Keith; Christian Ehrhardt; Stephen Hemminger; dev
> Subject: Re: [dpdk-dev] [RFC PATCH] replace DPDK config and build
> system
> 
> On Tue, Jun 20, 2017 at 03:34:58PM +0200, Morten Brørup wrote:
> > FYI: We are using Crosstool-NG (http://crosstool-ng.github.io/). It
> seems to be quite popular for cross compiling.
> >
> 
> How does a tool like that interact with build-systems then - either
> with our current one, or with a hypothetical future one using
> meson+ninja as below? Does it simplify what needs to be provided in the
> build config tool?
> 
> /Bruce

The main purpose of our build-system is to be able to just type "make" to build everything in our project (including the cross compiler itself). The purpose is not to simplify the build config tool for each of the libraries and executables in our project.

Please note that standardization is a benefit in itself! If every 3rd party library and executable in a complex project like ours had completely different build-systems, it would be a nightmare for us to maintain our project.

And to answer your question: Basically when using cross-tools, we set up a bunch of environment variables and then call the Makefile of each library and executable in the project (to configure and/or compile them). These environment variables are somewhat standardized, so modifying a Makefile for a 3rd party library/executable that is not designed for cross compiling is only a minor pain, not a major pain. I haven't looked at meson+ninja, but from reading the discussion here, it seems somewhat similar.

If DPDK switches to meson+ninja we will make it work for us too, so I'm not opposing such a change. I only wanted to highlight that Crosstool-NG is a very popular cross compiling environment, and has a good track record in this area.


Med venlig hilsen / kind regards
- Morten Brørup

Re: [dpdk-dev] [RFC PATCH] replace DPDK config and build system

[Bruce Richardson]

On Tue, Jun 20, 2017 at 04:25:12PM +0200, Morten Brørup wrote:
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson
> > Sent: Tuesday, June 20, 2017 3:41 PM
> > To: Morten Brørup
> > Cc: Wiles, Keith; Christian Ehrhardt; Stephen Hemminger; dev
> > Subject: Re: [dpdk-dev] [RFC PATCH] replace DPDK config and build
> > system
> > 
> > On Tue, Jun 20, 2017 at 03:34:58PM +0200, Morten Brørup wrote:
> > > FYI: We are using Crosstool-NG (http://crosstool-ng.github.io/). It
> > seems to be quite popular for cross compiling.
> > >
> > 
> > How does a tool like that interact with build-systems then - either
> > with our current one, or with a hypothetical future one using
> > meson+ninja as below? Does it simplify what needs to be provided in the
> > build config tool?
> > 
> > /Bruce
> 
> The main purpose of our build-system is to be able to just type "make" to build everything in our project (including the cross compiler itself). The purpose is not to simplify the build config tool for each of the libraries and executables in our project.
> 
> Please note that standardization is a benefit in itself! If every 3rd party library and executable in a complex project like ours had completely different build-systems, it would be a nightmare for us to maintain our project.
> 
> And to answer your question: Basically when using cross-tools, we set up a bunch of environment variables and then call the Makefile of each library and executable in the project (to configure and/or compile them). These environment variables are somewhat standardized, so modifying a Makefile for a 3rd party library/executable that is not designed for cross compiling is only a minor pain, not a major pain. I haven't looked at meson+ninja, but from reading the discussion here, it seems somewhat similar.
> 
> If DPDK switches to meson+ninja we will make it work for us too, so I'm not opposing such a change. I only wanted to highlight that Crosstool-NG is a very popular cross compiling environment, and has a good track record in this area.
> 
> 
> Med venlig hilsen / kind regards
> - Morten Brørup
> 
Thanks for the clarification.

Re: [dpdk-dev] [RFC PATCH] replace DPDK config and build system

[Neil Horman]

On Wed, Jun 07, 2017 at 11:47:42AM +0100, Bruce Richardson wrote:
> Hi all,
> 
> following on from the pressing need to add support in DPDK for detecting
> and managing external dependencies, I undertook to see what options we had.
> However, unrelated to this, over time, I have become increasingly
> frustrated by the complexity of the DPDK configuration and build system. As
> such, I feel that looking at some of the newer build tools that are out
> there might give us the additional functionality we want, along with other
> benefits. As such, I undertook a prototype using "meson"[1] for
> configuration, which uses "ninja" as a backend for doing the actual build.
> 
> With these tools we get the following benefits (not a complete list):
> * support for detecting dependencies on the system
> * support for detecting compiler features, including functions, defines
> * improved maintainability through a high-level language, which gives
>   decent error messages including line numbers (!!)
> * co-existence with the existing makefile system without making any changes
>   to it
> * faster builds using ninja - on my many-core system, the builds seem
>   significantly faster than with our existing system. Especially in the
>   nothing-has-changed case, builds with my prototype return instantly,
>   compared to taking a few seconds to recursively check each directory with
>   the current build system
> * the ability to switch to using a standard "ninja" + "ninja install" setup
> * the chance to rework our existing build-config files, and hopefully
>   pretty much remove them.
> * pkg-config support.
> * we get to move away from our bespoke build system
> * dependencies in each lib can be moved back to being tracked in the libs
>   files themselves, not up a level
> 
> 
> Of course, it's not a panacea, but having spent hours on the prototype thus
> far, I find working with meson and ninja far more user-friendly than
> working on our makefiles, and again the build speed is a really nice
> improvment too.
> 
> The prototype is incomplete, but it does build a reasonable number of our
> libraries, some unit tests, the i40e PMD and the testpmd binary, and I have
> successfully passed traffic using testpmd from the build. Some things are
> not fully correct, e.g. static builds aren't working right now, as I haven't
> correctly done all the dependency tracking, I think, and the cpu flag
> detection has issues. It also has only been tried on x86_64 linux, on a
> couple of systems, so YMMV. However, I feel it's a reasonable enough start
> point to show what we might be able to achieve.
> 
> Please take the prototype and test it out. I think it's a better
> alternative to trying to bolt on additional functionality to our existing
> config and build system.
> 
> [1] http://mesonbuild.com/

A few notes:

1) It is quick for a native build, which is nice

2) Its seemingly much more clear to understand than the current Makefile system
(which is horribly opaque).  That said, its still not a particularly common
build system.  I wonder if there wouldn't be better reception to just cleaning
up the existing Makefiles, with something like autoconf.   That likely still
won't be as fast as ninja, but it will be common and well understood, and still
reasonably fast.

3) The tools that are needed here, aren't universally available.  I can speak to
RHEL specifically which doesn't have ninja currently, nor meson (they are
available in EPEL, but that can't be used for official builds). Its not an
insurmountable problem, but its something to consider when considering product
reach, and the impact this will have on distributions.

4) I'm a bit lost as to how inheritance works in meson (or if it exists at all).
All the examples you provide here seem to duplicate work.  For instance, several
libraries independently check  if dpdk_conf.has('RTE_MACHINE_CPUFLAG_SSE4_1')
and set proper cflags accordingly, rather than inheriting the flag from a higher
level.  While that in and of itself isn't a singular problem, it could well be a
problem at scale for more complex operations (see below)

5) I know you said this was just an incomplete prototype, which is fine, but I
noticed that the build it produces doesn't yield any pmd exported info (of the
type you would get using dpdk-pmdinfo.py).  Thats because the building of that
info requires a multi-stage build process, wherein .o files are post-processed
to generate new .c files, which are then compiled and linked into the final .so
or .a file.  While I think I see how you might use the gen_src and custom_target
rules to make that happen, the (supposed) lack of inheritance noted above, could
lead to the duplication of alot of fairly complex rules that would have to be
distributed to every pmd in the system.  Thats something to consider.

6) Integration with other build systems.  We build some kernel modules in dpdk
that likely need to remain as part of the make build system (they don't have to,
I suppose, but it would seem like alot of effort to change that).  Is using
something non-make going to fit there?

Just a few thoughts.  All in all the speed is nice, but I think theres alot to
consider before dumping Make.  Not so much because Make is great, but because
its common, and well understood, and integrated with other projects.

Neil

Re: [dpdk-dev] [RFC PATCH] replace DPDK config and build system

[Bruce Richardson]

On Thu, Jun 22, 2017 at 01:14:54PM -0400, Neil Horman wrote:
> On Wed, Jun 07, 2017 at 11:47:42AM +0100, Bruce Richardson wrote:
> > Hi all,
> > 
> > following on from the pressing need to add support in DPDK for detecting
> > and managing external dependencies, I undertook to see what options we had.
> > However, unrelated to this, over time, I have become increasingly
> > frustrated by the complexity of the DPDK configuration and build system. As
> > such, I feel that looking at some of the newer build tools that are out
> > there might give us the additional functionality we want, along with other
> > benefits. As such, I undertook a prototype using "meson"[1] for
> > configuration, which uses "ninja" as a backend for doing the actual build.
> > 
> > With these tools we get the following benefits (not a complete list):
> > * support for detecting dependencies on the system
> > * support for detecting compiler features, including functions, defines
> > * improved maintainability through a high-level language, which gives
> >   decent error messages including line numbers (!!)
> > * co-existence with the existing makefile system without making any changes
> >   to it
> > * faster builds using ninja - on my many-core system, the builds seem
> >   significantly faster than with our existing system. Especially in the
> >   nothing-has-changed case, builds with my prototype return instantly,
> >   compared to taking a few seconds to recursively check each directory with
> >   the current build system
> > * the ability to switch to using a standard "ninja" + "ninja install" setup
> > * the chance to rework our existing build-config files, and hopefully
> >   pretty much remove them.
> > * pkg-config support.
> > * we get to move away from our bespoke build system
> > * dependencies in each lib can be moved back to being tracked in the libs
> >   files themselves, not up a level
> > 
> > 
> > Of course, it's not a panacea, but having spent hours on the prototype thus
> > far, I find working with meson and ninja far more user-friendly than
> > working on our makefiles, and again the build speed is a really nice
> > improvment too.
> > 
> > The prototype is incomplete, but it does build a reasonable number of our
> > libraries, some unit tests, the i40e PMD and the testpmd binary, and I have
> > successfully passed traffic using testpmd from the build. Some things are
> > not fully correct, e.g. static builds aren't working right now, as I haven't
> > correctly done all the dependency tracking, I think, and the cpu flag
> > detection has issues. It also has only been tried on x86_64 linux, on a
> > couple of systems, so YMMV. However, I feel it's a reasonable enough start
> > point to show what we might be able to achieve.
> > 
> > Please take the prototype and test it out. I think it's a better
> > alternative to trying to bolt on additional functionality to our existing
> > config and build system.
> > 
> > [1] http://mesonbuild.com/
> 
> A few notes:

Hi Neil,

thanks for taking a look at this. I agree with all your notes below, and
added some comments of my own to each point below. Overall, I fully
agree with your conclusion that it's too early to dump make - even the
best case plans envisaged for this, would not see make dropped for quite a
number of releases [if ever].

> 
> 1) It is quick for a native build, which is nice
> 
> 2) Its seemingly much more clear to understand than the current Makefile system
> (which is horribly opaque).  That said, its still not a particularly common
> build system.  I wonder if there wouldn't be better reception to just cleaning
> up the existing Makefiles, with something like autoconf.   That likely still
> won't be as fast as ninja, but it will be common and well understood, and still
> reasonably fast.

Sure, that is an option. I decided to look for alternatives mainly
because IIRC any mention of autotools in the past has met a very negative
reaction on-list. I could be wrong on this but I got the general
impression that many thought an autotools cure was better than the
disease! :-) Secondly, working with a non-makefile based system allows
old and new systems to co-exist for as long as we want them too, without
having to do a wholesale replacement, or go to great lengths to manage
the two within the one set of (make)files.

> 
> 3) The tools that are needed here, aren't universally available.  I can speak to
> RHEL specifically which doesn't have ninja currently, nor meson (they are
> available in EPEL, but that can't be used for official builds). Its not an
> insurmountable problem, but its something to consider when considering product
> reach, and the impact this will have on distributions.

I'll admit that meson is fairly new, but from what I read it is also
gaining quite a bit of acceptance in the gnome world at least, so it's
not really that obscure a system. Ninja, on the other hand, has been
around since 2011, and is widely used by many other tools, e.g. cmake,
gyp and meson, and projects like chromium, or llvm, so I'm a bit
surprised that is is not in RHEL. Are other packages compiled using
ninja in RHEL?

> 
> 4) I'm a bit lost as to how inheritance works in meson (or if it exists at all).
> All the examples you provide here seem to duplicate work.  For instance, several
> libraries independently check  if dpdk_conf.has('RTE_MACHINE_CPUFLAG_SSE4_1')
> and set proper cflags accordingly, rather than inheriting the flag from a higher
> level.  While that in and of itself isn't a singular problem, it could well be a
> problem at scale for more complex operations (see below)

Yep, good point. Things like that I would always initially blame on my
novice implementation as I was learning meson as I went along. If it is
really a problem, doing a full implementation should quickly show that
up, and we can go back to the drawing board.

> 
> 5) I know you said this was just an incomplete prototype, which is fine, but I
> noticed that the build it produces doesn't yield any pmd exported info (of the
> type you would get using dpdk-pmdinfo.py).  Thats because the building of that
> info requires a multi-stage build process, wherein .o files are post-processed
> to generate new .c files, which are then compiled and linked into the final .so
> or .a file.  While I think I see how you might use the gen_src and custom_target
> rules to make that happen, the (supposed) lack of inheritance noted above, could
> lead to the duplication of alot of fairly complex rules that would have to be
> distributed to every pmd in the system.  Thats something to consider.

Yep. I explicitly decided not to tackle the pmdinfo stuff for the
prototype, but I hadn't considered the implications for duplication in
the build files. I'll try and dig into this soon before we invest
serious work into this.

> 
> 6) Integration with other build systems.  We build some kernel modules in dpdk
> that likely need to remain as part of the make build system (they don't have to,
> I suppose, but it would seem like alot of effort to change that).  Is using
> something non-make going to fit there?

I was assuming we'd still use make for the kernel modules, but haven't
tried to see how that would work yet.

> 
> Just a few thoughts.  All in all the speed is nice, but I think theres alot to
> consider before dumping Make.  Not so much because Make is great, but because
> its common, and well understood, and integrated with other projects.
> 
Yep, at this point I'd rate it as "definitely worth looking at further",
rather than a definite commitment to replace what we have.
I'm aiming to start doing a post-prototype implementation in a staging
tree in the near future and we can see how that shapes up.

/Bruce