dpdk: new package
v3 cover dpdk: new package
Hello all,
this my thrid approach to upstream support of the DPDK into Buildroot. Briefly:
* The DPDK is a library (www.dpdk.org) that allows high-speed (10-100 Gbps) packet sending/receiving at very high packet rates while bypassing the Linux Kernel.
* I maintain the ARM(v7) part of the DPDK so I am interested in building DPDK by Buildroot.
* The DPDK tests require pexpect and ptyprocess python packages to run so they are included.
Changes for v3:
* Line overfull fixes (all patches).
* Hopefully solved issues reported by T. Petazzoni.
* As using a newer DPDK, the patch now utilizes the new installation infra.
* I've decided to include building of example applications, however, it is not built nor installed in a standardized way, so, it's done by dpdk.mk.
Jan Viktorin (3):
python-ptyprocess: new package
python-pexpect: new package
dpdk: new package
package/Config.in | 3 + package/dpdk/Config.in | 53 ++++++++++++ package/dpdk/dpdk.hash | 2 + package/dpdk/dpdk.mk | 109 +++++++++++++++++++++++++ package/python-pexpect/Config.in | 11 +++ package/python-pexpect/python-pexpect.mk | 14 ++++ package/python-ptyprocess/Config.in | 7 ++ package/python-ptyprocess/python-ptyprocess.mk | 13 +++ 8 files changed, 212 insertions(+) create mode 100644 package/dpdk/Config.in create mode 100644 package/dpdk/dpdk.hash create mode 100644 package/dpdk/dpdk.mk create mode 100644 package/python-pexpect/Config.in create mode 100644 package/python-pexpect/python-pexpect.mk create mode 100644 package/python-ptyprocess/Config.in create mode 100644 package/python-ptyprocess/python-ptyprocess.mk
Signature · 1 line
2.7.0
PATCH v3 1/3 python-ptyprocess: new package
--- package/Config.in | 1 + package/python-ptyprocess/Config.in | 7 +++++++ package/python-ptyprocess/python-ptyprocess.mk | 13 +++++++++++++ 3 files changed, 21 insertions(+) create mode 100644 package/python-ptyprocess/Config.in create mode 100644 package/python-ptyprocess/python-ptyprocess.mk
package/Config.in +1 -0
@@ -689,6 +689,7 @@ menu "External python modules" source "package/python-posix-ipc/Config.in" source "package/python-protobuf/Config.in" source "package/python-psutil/Config.in" + source "package/python-ptyprocess/Config.in" source "package/python-pyasn/Config.in" source "package/python-pyasn-modules/Config.in" source "package/python-pycli/Config.in"
package/python-ptyprocess/Config.in new file +7 -0
@@ -0,0 +1,7 @@ +config BR2_PACKAGE_PYTHON_PTYPROCESS + bool "python-ptyprocess" + help + Launch a subprocess in a pseudo terminal (pty), and interact with + both the process and its pty. + + https://github.com/pexpect/ptyprocess
package/python-ptyprocess/python-ptyprocess.mk new file +13 -0
@@ -0,0 +1,13 @@ +################################################################################ +# +# python-ptyprocess +# +################################################################################ + +PYTHON_PTYPROCESS_VERSION = 0.5 +PYTHON_PTYPROCESS_SITE = $(call github,pexpect,ptyprocess,$(PYTHON_PTYPROCESS_VERSION)) +PYTHON_PTYPROCESS_LICENSE = ISC +PYTHON_PTYPROCESS_LICENSE_FILES = LICENSE +PYTHON_PTYPROCESS_SETUP_TYPE = distutils + +$(eval $(python-package))
Signature · 1 line
2.7.0
PATCH v3 1/3 python-ptyprocess: new package
Hi Jan,
the patch looks good to me. Below some comments:
Quoted 40 lines · Jan Viktorin
Signed-off-by Jan Viktorin <[email protected]>--- package/Config.in | 1 + package/python-ptyprocess/Config.in | 7 +++++++ package/python-ptyprocess/python-ptyprocess.mk | 13 +++++++++++++ 3 files changed, 21 insertions(+) create mode 100644 package/python-ptyprocess/Config.in create mode 100644 package/python-ptyprocess/python-ptyprocess.mkpackage/Config.in +1
-0@@ -689,6 +689,7 @@ menu "External python modules" source "package/python-posix-ipc/Config.in" source "package/python-protobuf/Config.in" source "package/python-psutil/Config.in" + source "package/python-ptyprocess/Config.in" source "package/python-pyasn/Config.in" source "package/python-pyasn-modules/Config.in" source "package/python-pycli/Config.in"package/python-ptyprocess/Config.in new file +7
-0@@ -0,0 +1,7 @@ +config BR2_PACKAGE_PYTHON_PTYPROCESS + bool "python-ptyprocess" + help + Launch a subprocess in a pseudo terminal (pty), and interact with + both the process and its pty. + + https://github.com/pexpect/ptyprocesspackage/python-ptyprocess/python-ptyprocess.mk new file +0
-0
package/python-ptyprocess/python-ptyprocess.mk line 7
Quoted 7 lines
package/python-ptyprocess/python-ptyprocess.mk new file +7
-0@@ -0,0 +1,13 @@ +################################################################################ +# +# python-ptyprocess +# +################################################################################ + +PYTHON_PTYPROCESS_VERSION = 0.5
There is newer version available 0.5.1
package/python-ptyprocess/python-ptyprocess.mk line 8
Quoted 1 line
package/python-ptyprocess/python-ptyprocess.mk new file +1
-0+PYTHON_PTYPROCESS_SITE = $(call github,pexpect,ptyprocess,$(PYTHON_PTYPROCESS_VERSION))
Please get the package from https://pypi.python.org/pypi/ptyprocess
and add a hash file.
package/python-ptyprocess/python-ptyprocess.mk line 13
Quoted 5 lines
package/python-ptyprocess/python-ptyprocess.mk new file +5
-0+PYTHON_PTYPROCESS_LICENSE = ISC +PYTHON_PTYPROCESS_LICENSE_FILES = LICENSE +PYTHON_PTYPROCESS_SETUP_TYPE = distutils + +$(eval $(python-package))
Yegor
PATCH v3 2/3 python-pexpect: new package
In reply to Jan Viktorin--- package/Config.in | 1 + package/python-pexpect/Config.in | 11 +++++++++++ package/python-pexpect/python-pexpect.mk | 14 ++++++++++++++ 3 files changed, 26 insertions(+) create mode 100644 package/python-pexpect/Config.in create mode 100644 package/python-pexpect/python-pexpect.mk
package/Config.in +1 -0
@@ -686,6 +686,7 @@ menu "External python modules" source "package/python-paho-mqtt/Config.in" source "package/python-pam/Config.in" source "package/python-paramiko/Config.in" + source "package/python-pexpect/Config.in" source "package/python-posix-ipc/Config.in" source "package/python-protobuf/Config.in" source "package/python-psutil/Config.in"
package/python-pexpect/Config.in new file +11 -0
@@ -0,0 +1,11 @@ +config BR2_PACKAGE_PYTHON_PEXPECT + bool "python-pexpect" + select BR2_PACKAGE_PYTHON_PTYPROCESS + help + Pexpect is a pure Python module for spawning child applications; + controlling them; and responding to expected patterns in their + output. Pexpect works like Don Libes? Expect. Pexpect allows your + script to spawn a child application and control it as if a human + were typing commands. + + https://pexpect.readthedocs.org
package/python-pexpect/python-pexpect.mk new file +14 -0
@@ -0,0 +1,14 @@ +################################################################################ +# +# python-pexpect +# +################################################################################ + +PYTHON_PEXPECT_VERSION = 4.0.1 +PYTHON_PEXPECT_SITE = $(call github,pexpect,pexpect,$(PYTHON_PEXPECT_VERSION)) +PYTHON_PEXPECT_LICENSE = ISC +PYTHON_PEXPECT_LICENSE_FILES = LICENSE +PYTHON_PEXPECT_SETUP_TYPE = distutils +PYTHON_PEXPECT_DEPENDENCIES = python-ptyprocess + +$(eval $(python-package))
Signature · 1 line
2.7.0
PATCH v3 2/3 python-pexpect: new package
Hi Jan,
Quoted 44 lines · Jan Viktorin
Signed-off-by Jan Viktorin <[email protected]>--- package/Config.in | 1 + package/python-pexpect/Config.in | 11 +++++++++++ package/python-pexpect/python-pexpect.mk | 14 ++++++++++++++ 3 files changed, 26 insertions(+) create mode 100644 package/python-pexpect/Config.in create mode 100644 package/python-pexpect/python-pexpect.mkpackage/Config.in +1
-0@@ -686,6 +686,7 @@ menu "External python modules" source "package/python-paho-mqtt/Config.in" source "package/python-pam/Config.in" source "package/python-paramiko/Config.in" + source "package/python-pexpect/Config.in" source "package/python-posix-ipc/Config.in" source "package/python-protobuf/Config.in" source "package/python-psutil/Config.in"package/python-pexpect/Config.in new file +11
-0@@ -0,0 +1,11 @@ +config BR2_PACKAGE_PYTHON_PEXPECT + bool "python-pexpect" + select BR2_PACKAGE_PYTHON_PTYPROCESS + help + Pexpect is a pure Python module for spawning child applications; + controlling them; and responding to expected patterns in their + output. Pexpect works like Don Libes? Expect. Pexpect allows your + script to spawn a child application and control it as if a human + were typing commands. + + https://pexpect.readthedocs.orgpackage/python-pexpect/python-pexpect.mk new file +0
-0
package/python-pexpect/python-pexpect.mk line 8
Quoted 8 lines
package/python-pexpect/python-pexpect.mk new file +8
-0@@ -0,0 +1,14 @@ +################################################################################ +# +# python-pexpect +# +################################################################################ + +PYTHON_PEXPECT_VERSION = 4.0.1 +PYTHON_PEXPECT_SITE = $(call github,pexpect,pexpect,$(PYTHON_PEXPECT_VERSION))
Please get the package from https://pypi.python.org/pypi/pexpect and add a hash file.
package/python-pexpect/python-pexpect.mk line 12
Quoted 4 lines
package/python-pexpect/python-pexpect.mk new file +4
-0+PYTHON_PEXPECT_LICENSE = ISC +PYTHON_PEXPECT_LICENSE_FILES = LICENSE +PYTHON_PEXPECT_SETUP_TYPE = distutils +PYTHON_PEXPECT_DEPENDENCIES = python-ptyprocess
remove this build-time dependency
Quoted 5 lines
package/python-pexpect/python-pexpect.mk new file +2
-1+ +$(eval $(python-package)) --2.7.0
PATCH v3 3/3 dpdk: new package
In reply to Jan ViktorinThis patch introduces support of the DPDK library (www.dpdk.org) into Buildroot. DPDK is a library for high-speed packet sending/receiving while bypassing the Linux Kernel. It allows to reach a high throughput for 10-100 Gbps networks on the x86 platform.
The package compiles and installs DPDK libraries on the target and staging and allows to compile other applications depending on the DPDK library. It can also install some basic tools the DPDK provides (testpmd, python scripts, test suite).
The patch assumes DPDK 16.04-rc1. This version contains support for the ARM architecture. The ARM ports can be tested by
qemu_aarch64_virt_defconfig
qemu_arm_vexpress_defconfig
The included hash was calculated locally by downloading the tar.gz archives by hand.
There are unfortunately some pitfalls:
* it may require to enable PCI, MSIX, UIO in the Linux Kernel (some defconfigs does not include as default and it is platform dependent as ARMv7 almost does not use PCI)
* when building PCAP PMD driver, the libpcap is required (partially fixed as suggested by Arnout)
* some tools the DPDK provides depend on Python(2) so the user has to enable it to install those
---
v2: (mostly suggestions by Arnout)
* simplified Config.in - avoid version, source and config selection
* improved dependency on libpcap
* user python scripts are included if python package is enabled
* installing of tests includes autotest*.py scripts (we do not care about the python here, assuming the user will install it manually when testing)
* minor coding style fixes
* depends on python-pexpect package
* using version 2.2.0-rc3
v3
* bump to version 16.04-rc1
* utilizing the new install syntax of DPDK
* fixed line wrapping
* testpmd is now always installed (no option for this)
* fixed python dependencies (T. Petazzoni)
* supporting i686+ architectures (T. Petazzoni)
* dropped PPC support for now (T. Petazzoni)
* utilizing KCONFIG_ENABLE_OPT macro (T. Petazzoni)
* support for build & install of examples (ugly code)
* build with MAKE instead of MAKE1 seems OK now (T. Petazzoni)
* dropped COMBINE_LIBS (no more in DPDK) (T. Petazzoni)
* added HAS_SYNC_x
* few random fixes
--- package/Config.in | 1 + package/dpdk/Config.in | 53 ++++++++++++++++++++++++ package/dpdk/dpdk.hash | 2 + package/dpdk/dpdk.mk | 109 +++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 165 insertions(+) create mode 100644 package/dpdk/Config.in create mode 100644 package/dpdk/dpdk.hash create mode 100644 package/dpdk/dpdk.mk
package/Config.in +1 -0
@@ -1095,6 +1095,7 @@ menu "Networking" source "package/cgic/Config.in" source "package/cppzmq/Config.in" source "package/czmq/Config.in" + source "package/dpdk/Config.in" source "package/filemq/Config.in" source "package/flickcurl/Config.in" source "package/fmlib/Config.in"
package/dpdk/Config.in new file +53 -0
53 lines not on this page · raw message
package/dpdk/dpdk.hash new file +2 -0
@@ -0,0 +1,2 @@ +# Locally calculated +sha256 18df4b6ac74a4383b65d7c79420b637d0c296636265388dbf4513d1ec5caa09f dpdk-16.04-rc1.tar.gz
package/dpdk/dpdk.mk new file +109 -0
109 lines not on this page · raw message
Signature · 1 line
2.7.0
PATCH v3 3/3 dpdk: new package
Hello,
package/dpdk/Config.in line 2
Quoted 8 lines · Jan Viktorin
package/dpdk/Config.in new file +2
-0@@ -0,0 +1,53 @@ +config BR2_PACKAGE_DPDK + bool "dpdk"
Indentation of properties should be done with one tab (ditto in the following lines)
package/dpdk/Config.in line 5
Quoted 3 lines
package/dpdk/Config.in new file +3
-0+ depends on (BR2_i386 && !BR2_x86_i386 && !BR2_x86_i486 \ + && !BR2_x86_i586 && !BR2_x86_x1000) \ + || BR2_ARM_CPU_ARMV7A || BR2_aarch64 || BR2_aarch64_be
I'm wondering why you have this list of architecture dependencies. Is it because there is really some architecture specific code, or is it a left-over from the times we didn't had the BR2_TOOLCHAIN_HAS_x options ?
If that's really needed, please add a blind option like this:
config BR2_PACKAGE_DPDK_ARCH_SUPPORTS
bool
default y if ...
That you can re-use as a dependency, both for the comment (see below) and the main option.
package/dpdk/Config.in line 6
Quoted 1 line
package/dpdk/Config.in new file +1
-0+ depends on BR2_TOOLCHAIN_USES_GLIBC
Then you need to have a comment like:
comment "dpdk needs a toolchain w/ glibc"
depends on !BR2_TOOLCHAIN_USES_GLIBC
depends on BR2_TOOLCHAIN_HAS_SYNC_...
package/dpdk/Config.in line 10
Quoted 4 lines
package/dpdk/Config.in new file +4
-0+ depends on BR2_TOOLCHAIN_HAS_SYNC_1 + depends on BR2_TOOLCHAIN_HAS_SYNC_2 + depends on BR2_TOOLCHAIN_HAS_SYNC_4 + depends on BR2_TOOLCHAIN_HAS_SYNC_8
Cosmetic nit, but I would prefer to see:
depends on BR2_TOOLCHAIN_HAS_SYNC_1 && \ BR2_TOOLCHAIN_HAS_SYNC_2 && \ BR2_TOOLCHAIN_HAS_SYNC_4 && \ BR2_TOOLCHAIN_HAS_SYNC_8
package/dpdk/Config.in line 16
Quoted 6 lines
package/dpdk/Config.in new file +6
-0+ help + DPDK is a set of libraries and drivers for fast packet processing. It + was designed to run on any processors, however, Intel x86 has been the + first CPU to be supported. Ports for other CPUs like IBM Power 8 and + ARM are under progress. It runs mostly in Linux userland. A FreeBSD + port is now available for a subset of DPDK features.
Indentation of the help text should be one tab + *two* spaces.
Quoted 13 lines
package/dpdk/Config.in new file +13
-0+ + Notes: + * To build the included Linux Kernel drivers, it is necessary to + enable CONFIG_PCI_MSI, CONFIG_UIO. + * To build the PCAP PMD properly, you need to enable the libpcap + manually. + * You may need to install the python2 interpreter if you want to use + scripts dpdk_nic_bind.py and cpu_layout.py + + http://www.dpdk.org/ + +if BR2_PACKAGE_DPDK +
package/dpdk/Config.in line 39
Quoted 10 lines
package/dpdk/Config.in new file +10
-0+config BR2_PACKAGE_DPDK_CONFIG + string "Configuration" + default "i686-native-linuxapp-gcc" \ + if BR2_x86_i686 + default "x86_64-native-linuxapp-gcc" \ + if BR2_x86_64 + default "arm-armv7a-linuxapp-gcc" \ + if BR2_ARM_CPU_ARMV7A + default "arm64-armv8a-linuxapp-gcc" \ + if BR2_aarch64 || BR2_aarch64_be
I don't remember if we discussed this: is there any reason to make this configurable? I.e is it necessary to make it a visible Config.in option as opposed to a blind one?
package/dpdk/Config.in line 46
Quoted 7 lines
package/dpdk/Config.in new file +7
-0+ +config BR2_PACKAGE_DPDK_TEST + bool "Install tests suite" + select BR2_PACKAGE_PYTHON_PEXPECT if BR2_PACKAGE_PYTHON + help + Install all DPDK tests. If you want to run the tests by the included + autotest.py script you need to enable python manually.
Is the test suite usable without Python ?
package/dpdk/dpdk.mk line 7
Quoted 13 lines
package/dpdk/dpdk.mk new file +7
-0@@ -0,0 +1,109 @@ +################################################################################ +# +# dpdk +# +################################################################################ + +DPDK_VERSION = 16.04-rc1
We normally don't package release candidate / beta version. Are you confident that the final 16.04 release will be done before Buildroot ships its own release at the end of May ?
package/dpdk/dpdk.mk line 9
Quoted 2 lines
package/dpdk/dpdk.mk new file +2
-0+DPDK_SITE = http://dpdk.org/browse/dpdk/snapshot +DPDK_SOURCE = dpdk-$(DPDK_VERSION).tar.gz
Not needed, that's the default value.
package/dpdk/dpdk.mk line 11
Quoted 2 lines
package/dpdk/dpdk.mk new file +2
-0+ +DPDK_LICENSE = BSD (core), GPLv2+ (Linux drivers)
BSD should be more specific, like BSD-2c, BSD-3c, etc.
package/dpdk/dpdk.mk line 15
Quoted 4 lines
package/dpdk/dpdk.mk new file +4
-0+DPDK_LICENSE_FILES = GNUmakefile LICENSE.GPL +DPDK_INSTALL_STAGING = YES + +DPDK_DEPENDENCIES += linux
If you need the Linux kernel to be built, then you need to also have:
depends on BR2_LINUX_KERNEL
in your Config.in, as well as a corresponding comment:
comment "dpdk needs the Linux kernel to be built"
depends on !BR2_LINUX_KERNEL
Quoted 9 lines
package/dpdk/dpdk.mk new file +9
-0+ +ifeq ($(BR2_PACKAGE_LIBPCAP),y) +DPDK_DEPENDENCIES += libpcap +endif + +ifeq ($(BR2_SHARED_LIBS),y) +define DPDK_ENABLE_SHARED_LIBS + $(call KCONFIG_ENABLE_OPT,CONFIG_RTE_BUILD_SHARED_LIB,\ + $(@D)/build/.config)
package/dpdk/dpdk.mk line 34
Quoted 10 lines
package/dpdk/dpdk.mk new file +10
-0+endef + +DPDK_POST_CONFIGURE_HOOKS += DPDK_ENABLE_SHARED_LIBS +endif + +# We're building a kernel module without using the kernel-module infra, +# so we need to tell we want module support in the kernel +ifeq ($(BR2_PACKAGE_DPDK),y) +LINUX_NEEDS_MODULES = y +endif
This is no longer the "right" way of doing this. Just select BR2_LINUX_NEEDS_MODULES in Config.in.
Quoted 13 lines
package/dpdk/dpdk.mk new file +13
-0+ +DPDK_CONFIG = $(call qstrip,$(BR2_PACKAGE_DPDK_CONFIG)) + +ifeq ($(BR2_PACKAGE_DPDK_EXAMPLES),y) +# Build of DPDK examples is not very straight-forward. It requires to have +# the SDK and runtime installed on same place to reference it by RTE_SDK. +# We place it locally in the build directory. +define DPDK_BUILD_EXAMPLES + $(MAKE) -C $(@D) DESTDIR=$(@D)/examples-sdk \ + CROSS=$(TARGET_CROSS) install-sdk install-runtime + $(MAKE) -C $(@D) RTE_KERNELDIR=$(LINUX_DIR) CROSS=$(TARGET_CROSS) \ + RTE_SDK=$(@D)/examples-sdk/usr/local/share/dpdk \ + T=$(DPDK_CONFIG) examples
package/dpdk/dpdk.mk line 57
Quoted 10 lines
package/dpdk/dpdk.mk new file +10
-0+endef + +DPDK_EXAMPLES_PATH = $(@D)/examples-sdk/usr/local/share/dpdk/examples + +# Installation of examples is not supported in DPDK so we do it explicitly +# here. As the binaries and libraries do not have a single or regular location +# where to find them after build, we search for them by find. +define DPDK_INSTALL_EXAMPLES + $(INSTALL) -m 0755 -d $(TARGET_DIR)/usr/local/bin + $(INSTALL) -m 0755 -d $(TARGET_DIR)/usr/local/lib
In Buildroot, everything is installed in /usr, not /usr/local. Why should this package be different? Also, to create directories, we typically use mkdir -p.
package/dpdk/dpdk.mk line 67
Quoted 10 lines
package/dpdk/dpdk.mk new file +10
-0+ for f in `find $(DPDK_EXAMPLES_PATH) -executable -type f \ + -name '[a-z]*.so*' | grep '\/lib\/.*'`; do \ + $(INSTALL) -m 0755 -D $$f \ + $(TARGET_DIR)/usr/local/lib/`basename $$f`;\ + done + for f in `find $(DPDK_EXAMPLES_PATH) -executable -type f \ + ! -name '*.so*' | grep '\/app\/.*'`; do \ + $(INSTALL) -m 0755 -D $$f \ + $(TARGET_DIR)/usr/local/bin/`basename $$f`;\ + done
It's a bit annoying to have this logic. Could it be simplified to use -path instead of -name and avoid the grep ?
Also, you need to add || exit 1 after the $(INSTALL) to exit the for loop in case of failure.
Ideally (but separately from this patch), you could contribute to upstream dpdk a way to install examples.
Quoted 32 lines
package/dpdk/dpdk.mk new file +32
-0+endef + +# Build of the power example is broken (at least for 16.04). +define DPDK_DISABLE_POWER + $(call KCONFIG_DISABLE_OPT,CONFIG_RTE_LIBRTE_POWER,\ + $(@D)/build/.config) +endef + +DPDK_POST_CONFIGURE_HOOKS += DPDK_DISABLE_POWER +endif + +define DPDK_CONFIGURE_CMDS + $(MAKE) -C $(@D) T=$(DPDK_CONFIG) RTE_KERNELDIR=$(LINUX_DIR) \ + CROSS=$(TARGET_CROSS) config +endef + +define DPDK_BUILD_CMDS + $(MAKE) -C $(@D) RTE_KERNELDIR=$(LINUX_DIR) CROSS=$(TARGET_CROSS) + $(DPDK_BUILD_EXAMPLES) +endef + +define DPDK_INSTALL_STAGING_CMDS + $(MAKE) -C $(@D) DESTDIR=$(STAGING_DIR) prefix=/usr \ + CROSS=$(TARGET_CROSS) install-sdk +endef + +ifeq ($(BR2_PACKAGE_DPDK_TEST),y) +define DPDK_INSTALL_TARGET_TEST + $(INSTALL) -m 0755 -d $(TARGET_DIR)/usr/dpdk + $(INSTALL) -m 0755 -D $(@D)/build/app/test $(TARGET_DIR)/usr/dpdk + $(INSTALL) -m 0755 -D $(@D)/app/test/*.py $(TARGET_DIR)/usr/dpdk +endef
package/dpdk/dpdk.mk line 109
Quoted 10 lines
package/dpdk/dpdk.mk new file +10
-0+endif + +define DPDK_INSTALL_TARGET_CMDS + $(MAKE) -C $(@D) DESTDIR=$(TARGET_DIR) prefix=/usr \ + CROSS=$(TARGET_CROSS) install-runtime + $(DPDK_INSTALL_TARGET_TEST) + $(DPDK_INSTALL_EXAMPLES) +endef + +$(eval $(generic-package))
Other than that, looks good to me.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH v3 3/3 dpdk: new package
Hello Thomas,,
thank you for comments. You can find your previous review here:
[1] http://lists.busybox.net/pipermail/buildroot/2015-December/146614.html
[2] http://lists.busybox.net/pipermail/buildroot/2015-December/146630.html
Quoted 16 lines · On Tue, 22 Mar 2016 21:12:32 +0100 Thomas Petazzoni…
Hello,
package/dpdk/Config.in line 2
Quoted 8 lines · Jan Viktorin
package/dpdk/Config.in new file +2
-0@@ -0,0 +1,53 @@ +config BR2_PACKAGE_DPDK + bool "dpdk"Indentation of properties should be done with one tab (ditto in the following lines)
Quoted 8 lines
package/dpdk/Config.in line 5
Quoted 3 lines
package/dpdk/Config.in new file +3
-0+ depends on (BR2_i386 && !BR2_x86_i386 && !BR2_x86_i486 \ + && !BR2_x86_i586 && !BR2_x86_x1000) \ + || BR2_ARM_CPU_ARMV7A || BR2_aarch64 || BR2_aarch64_beI'm wondering why you have this list of architecture dependencies. Is it because there is really some architecture specific code, or is it a left-over from the times we didn't had the
BR2_TOOLCHAIN_HAS_xoptions ?
Shortly: i686+ | ARMv7-a | AArch64, based on your suggestion [2]. Should I put a comment there?
Quoted 6 lines
If that's really needed, please add a blind option like this:
config
BR2_PACKAGE_DPDK_ARCH_SUPPORTS
bool
default y if ...
OK, seems reasonable.
Quoted 11 lines
That you can re-use as a dependency, both for the comment (see below) and the main option.
package/dpdk/Config.in line 6
Quoted 1 line
package/dpdk/Config.in new file +1
-0+ depends on BR2_TOOLCHAIN_USES_GLIBCThen you need to have a comment like:
comment "dpdk needs a toolchain w/ glibc"
depends on !BR2_TOOLCHAIN_USES_GLIBC
depends onBR2_TOOLCHAIN_HAS_SYNC_...
OK, will fix.
Quoted 6 lines
package/dpdk/Config.in line 10
Quoted 5 lines
package/dpdk/Config.in new file +4
-0+ depends on BR2_TOOLCHAIN_HAS_SYNC_1 + depends on BR2_TOOLCHAIN_HAS_SYNC_2 + depends on BR2_TOOLCHAIN_HAS_SYNC_4 + depends on BR2_TOOLCHAIN_HAS_SYNC_8
Quoted 6 lines
Cosmetic nit, but I would prefer to see:
depends on BR2_TOOLCHAIN_HAS_SYNC_1 && \ BR2_TOOLCHAIN_HAS_SYNC_2 && \ BR2_TOOLCHAIN_HAS_SYNC_4 && \ BR2_TOOLCHAIN_HAS_SYNC_8
Well, no problem, I just wonder why... as it's less readable and quite ugly :).
Quoted 11 lines
package/dpdk/Config.in line 16
Quoted 9 lines
package/dpdk/Config.in new file +6
-0+ help + DPDK is a set of libraries and drivers for fast packet processing. It + was designed to run on any processors, however, Intel x86 has been the + first CPU to be supported. Ports for other CPUs like IBM Power 8 and + ARM are under progress. It runs mostly in Linux userland. A FreeBSD + port is now available for a subset of DPDK features.Indentation of the help text should be one tab + *two* spaces.
The help text is right tab+ss, but the options are accidently indented by spaces. Will fix.
Quoted 20 lines
Quoted 20 lines
package/dpdk/Config.in new file +19
-0+ + Notes: + * To build the included Linux Kernel drivers, it is necessary to + enable CONFIG_PCI_MSI, CONFIG_UIO. + * To build the PCAP PMD properly, you need to enable the libpcap + manually. + * You may need to install the python2 interpreter if you want to use + scripts dpdk_nic_bind.py and cpu_layout.py + + http://www.dpdk.org/ + +if BR2_PACKAGE_DPDK + +config BR2_PACKAGE_DPDK_CONFIG + string "Configuration" + default "i686-native-linuxapp-gcc" \ + if BR2_x86_i686 + default "x86_64-native-linuxapp-gcc" \ + if BR2_x86_64
Quoted 8 lines
package/dpdk/Config.in line 39
Quoted 4 lines
package/dpdk/Config.in new file +4
-0+ default "arm-armv7a-linuxapp-gcc" \ + if BR2_ARM_CPU_ARMV7A + default "arm64-armv8a-linuxapp-gcc" \ + if BR2_aarch64 || BR2_aarch64_beI don't remember if we discussed this: is there any reason to make this configurable? I.e is it necessary to make it a visible Config.in option as opposed to a blind one?
You've already agreed on this [2] and it seems to be a good compromise. There are multiple configurations per CPU architecture and a user might want to use a custom one.
Quoted 10 lines
package/dpdk/Config.in line 46
Quoted 8 lines
package/dpdk/Config.in new file +7
-0+ +config BR2_PACKAGE_DPDK_TEST + bool "Install tests suite" + select BR2_PACKAGE_PYTHON_PEXPECT if BR2_PACKAGE_PYTHON + help + Install all DPDK tests. If you want to run the tests by the included + autotest.py script you need to enable python manually.Is the test suite usable without Python ?
Yes, it's compiled as a single binary _test_. I use it that way. The python scripts are helpful for automatization.
Quoted 10 lines
Quoted 10 lines
package/dpdk/dpdk.mk new file +3
-0@@ -0,0 +1,109 @@ +################################################################################ +# +# dpdk
Quoted 8 lines
package/dpdk/dpdk.mk line 7
Quoted 4 lines
package/dpdk/dpdk.mk new file +4
-0+# +################################################################################ + +DPDK_VERSION = 16.04-rc1We normally don't package release candidate / beta version. Are you confident that the final 16.04 release will be done before Buildroot ships its own release at the end of May ?
The release of 16.04 should be out early in April
(http://dpdk.org/dev/roadmap).
Quoted 5 lines
package/dpdk/dpdk.mk line 9
Quoted 3 lines
package/dpdk/dpdk.mk new file +2
-0+DPDK_SITE = http://dpdk.org/browse/dpdk/snapshot +DPDK_SOURCE = dpdk-$(DPDK_VERSION).tar.gzNot needed, that's the default value.
OK.
Quoted 5 lines
package/dpdk/dpdk.mk line 11
Quoted 3 lines
package/dpdk/dpdk.mk new file +2
-0+ +DPDK_LICENSE = BSD (core), GPLv2+ (Linux drivers)BSD should be more specific, like BSD-2c, BSD-3c, etc.
BSD-3c, thanks.
Quoted 8 lines
package/dpdk/dpdk.mk line 15
Quoted 5 lines
package/dpdk/dpdk.mk new file +4
-0+DPDK_LICENSE_FILES = GNUmakefile LICENSE.GPL +DPDK_INSTALL_STAGING = YES + +DPDK_DEPENDENCIES += linuxIf you need the Linux kernel to be built, then you need to also have:
Quoted 6 lines
depends on
BR2_LINUX_KERNELin your Config.in, as well as a corresponding comment:
comment "dpdk needs the Linux kernel to be built"
depends on !BR2_LINUX_KERNEL
OK.
Quoted 15 lines
Quoted 15 lines
package/dpdk/dpdk.mk new file +14
-0+ +ifeq ($(BR2_PACKAGE_LIBPCAP),y) +DPDK_DEPENDENCIES += libpcap +endif + +ifeq ($(BR2_SHARED_LIBS),y) +define DPDK_ENABLE_SHARED_LIBS + $(call KCONFIG_ENABLE_OPT,CONFIG_RTE_BUILD_SHARED_LIB,\ + $(@D)/build/.config) +endef + +DPDK_POST_CONFIGURE_HOOKS += DPDK_ENABLE_SHARED_LIBS +endif +
Quoted 8 lines
package/dpdk/dpdk.mk line 34
Quoted 5 lines
package/dpdk/dpdk.mk new file +5
-0+# We're building a kernel module without using the kernel-module infra, +# so we need to tell we want module support in the kernel +ifeq ($(BR2_PACKAGE_DPDK),y) +LINUX_NEEDS_MODULES = y +endifThis is no longer the "right" way of doing this. Just select
BR2_LINUX_NEEDS_MODULESin Config.in.
Cool, I didn't know that.
Quoted 18 lines
Quoted 18 lines
package/dpdk/dpdk.mk new file +17
-0+ +DPDK_CONFIG = $(call qstrip,$(BR2_PACKAGE_DPDK_CONFIG)) + +ifeq ($(BR2_PACKAGE_DPDK_EXAMPLES),y) +# Build of DPDK examples is not very straight-forward. It requires to have +# the SDK and runtime installed on same place to reference it by RTE_SDK. +# We place it locally in the build directory. +define DPDK_BUILD_EXAMPLES + $(MAKE) -C $(@D) DESTDIR=$(@D)/examples-sdk \ + CROSS=$(TARGET_CROSS) install-sdk install-runtime + $(MAKE) -C $(@D) RTE_KERNELDIR=$(LINUX_DIR) CROSS=$(TARGET_CROSS) \ + RTE_SDK=$(@D)/examples-sdk/usr/local/share/dpdk \ + T=$(DPDK_CONFIG) examples +endef + +DPDK_EXAMPLES_PATH = $(@D)/examples-sdk/usr/local/share/dpdk/examples +
Quoted 8 lines
package/dpdk/dpdk.mk line 57
Quoted 6 lines
package/dpdk/dpdk.mk new file +6
-0+# Installation of examples is not supported in DPDK so we do it explicitly +# here. As the binaries and libraries do not have a single or regular location +# where to find them after build, we search for them by find. +define DPDK_INSTALL_EXAMPLES + $(INSTALL) -m 0755 -d $(TARGET_DIR)/usr/local/bin + $(INSTALL) -m 0755 -d $(TARGET_DIR)/usr/local/libIn Buildroot, everything is installed in /usr, not
/usr/local. Why
Just testing the reviewers here :). Well, at first I wanted to easily check that it installs the right binaries and this is better checked in an empty directory then in the /usr/bin with a great amount of other things. I will put those into /usr/bin.
Quoted 2 lines
should this package be different? Also, to create directories, we typically use mkdir -p.
Will use mkdir -p.
Quoted 14 lines
package/dpdk/dpdk.mk line 67
Quoted 11 lines
package/dpdk/dpdk.mk new file +10
-0+ for f in `find $(DPDK_EXAMPLES_PATH) -executable -type f \ + -name '[a-z]*.so*' | grep '\/lib\/.*'`; do \ + $(INSTALL) -m 0755 -D $$f \ + $(TARGET_DIR)/usr/local/lib/`basename $$f`;\ + done + for f in `find $(DPDK_EXAMPLES_PATH) -executable -type f \ + ! -name '*.so*' | grep '\/app\/.*'`; do \ + $(INSTALL) -m 0755 -D $$f \ + $(TARGET_DIR)/usr/local/bin/`basename $$f`;\ + doneIt's a bit annoying to have this logic. Could it be simplified to use -path instead of -name and avoid the grep ?
OK, will try.
Quoted 3 lines
Also, you need to add || exit 1 after the $(INSTALL) to exit the for loop in case of failure.
OK, will fix.
Quoted 3 lines
Ideally (but separately from this patch), you could contribute to upstream dpdk a way to install examples.
True. First of all, I am happy to do it automatically at the moment. Of course, this is not the right place to solve it.
I'll try to patch this upstream and/or move this into a DPDK patch temporarily.
Quoted 37 lines
Quoted 37 lines
package/dpdk/dpdk.mk new file +36
-0+endef + +# Build of the power example is broken (at least for 16.04). +define DPDK_DISABLE_POWER + $(call KCONFIG_DISABLE_OPT,CONFIG_RTE_LIBRTE_POWER,\ + $(@D)/build/.config) +endef + +DPDK_POST_CONFIGURE_HOOKS += DPDK_DISABLE_POWER +endif + +define DPDK_CONFIGURE_CMDS + $(MAKE) -C $(@D) T=$(DPDK_CONFIG) RTE_KERNELDIR=$(LINUX_DIR) \ + CROSS=$(TARGET_CROSS) config +endef + +define DPDK_BUILD_CMDS + $(MAKE) -C $(@D) RTE_KERNELDIR=$(LINUX_DIR) CROSS=$(TARGET_CROSS) + $(DPDK_BUILD_EXAMPLES) +endef + +define DPDK_INSTALL_STAGING_CMDS + $(MAKE) -C $(@D) DESTDIR=$(STAGING_DIR) prefix=/usr \ + CROSS=$(TARGET_CROSS) install-sdk +endef + +ifeq ($(BR2_PACKAGE_DPDK_TEST),y) +define DPDK_INSTALL_TARGET_TEST + $(INSTALL) -m 0755 -d $(TARGET_DIR)/usr/dpdk + $(INSTALL) -m 0755 -D $(@D)/build/app/test $(TARGET_DIR)/usr/dpdk + $(INSTALL) -m 0755 -D $(@D)/app/test/*.py $(TARGET_DIR)/usr/dpdk +endef +endif + +define DPDK_INSTALL_TARGET_CMDS + $(MAKE) -C $(@D) DESTDIR=$(TARGET_DIR) prefix=/usr \
Quoted 8 lines
package/dpdk/dpdk.mk line 109
Quoted 6 lines
package/dpdk/dpdk.mk new file +6
-0+ CROSS=$(TARGET_CROSS) install-runtime + $(DPDK_INSTALL_TARGET_TEST) + $(DPDK_INSTALL_EXAMPLES) +endef + +$(eval $(generic-package))Other than that, looks good to me.
Thank you!
Jan
Quoted 2 lines
Thomas
Signature · 4 lines
Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic
PATCH v3 3/3 dpdk: new package
In reply to Thomas PetazzoniHello Thomas,
I've got some questions about the Config.in...
Quoted 25 lines · On Tue, 22 Mar 2016 21:12:32 +0100 Thomas Petazzoni…
Hello,
package/dpdk/Config.in line 2
Quoted 8 lines · Jan Viktorin
package/dpdk/Config.in new file +2
-0@@ -0,0 +1,53 @@ +config BR2_PACKAGE_DPDK + bool "dpdk"Indentation of properties should be done with one tab (ditto in the following lines)
package/dpdk/Config.in line 5
Quoted 3 lines
package/dpdk/Config.in new file +3
-0+ depends on (BR2_i386 && !BR2_x86_i386 && !BR2_x86_i486 \ + && !BR2_x86_i586 && !BR2_x86_x1000) \ + || BR2_ARM_CPU_ARMV7A || BR2_aarch64 || BR2_aarch64_beI'm wondering why you have this list of architecture dependencies. Is it because there is really some architecture specific code, or is it a left-over from the times we didn't had the
BR2_TOOLCHAIN_HAS_xoptions ?
Quoted 5 lines
If that's really needed, please add a blind option like this:
config
BR2_PACKAGE_DPDK_ARCH_SUPPORTS
bool
default y if ...
So, should I move here also the HAS_SYNC checks?
Quoted 11 lines
That you can re-use as a dependency, both for the comment (see below) and the main option.
package/dpdk/Config.in line 6
Quoted 1 line
package/dpdk/Config.in new file +1
-0+ depends on BR2_TOOLCHAIN_USES_GLIBCThen you need to have a comment like:
comment "dpdk needs a toolchain w/ glibc"
depends on !BR2_TOOLCHAIN_USES_GLIBC
depends onBR2_TOOLCHAIN_HAS_SYNC_...
The conditiion must be "if all dependencies but BR2_TOOLCHAIN_USES_GLIBC are met", is it right? So, should I put here the HAS_SYNC_*, ARCH_SUPPORTS, BR2_LINUX_KERNEL and BR2_LINUX_NEEDS_MODULES?
Quoted 12 lines
package/dpdk/Config.in line 10
Quoted 5 lines
package/dpdk/Config.in new file +4
-0+ depends on BR2_TOOLCHAIN_HAS_SYNC_1 + depends on BR2_TOOLCHAIN_HAS_SYNC_2 + depends on BR2_TOOLCHAIN_HAS_SYNC_4 + depends on BR2_TOOLCHAIN_HAS_SYNC_8Cosmetic nit, but I would prefer to see:
depends on BR2_TOOLCHAIN_HAS_SYNC_1 && \ BR2_TOOLCHAIN_HAS_SYNC_2 && \ BR2_TOOLCHAIN_HAS_SYNC_4 && \ BR2_TOOLCHAIN_HAS_SYNC_8
[...]
Quoted 6 lines
depends on
BR2_LINUX_KERNELin your Config.in, as well as a corresponding comment:
comment "dpdk needs the Linux kernel to be built"
depends on !BR2_LINUX_KERNEL
The same situation here. Should I test "all && !BR2_LINUX_KERNEL"?
Quoted 15 lines
Quoted 15 lines
package/dpdk/Config.in new file +14
-0+ +ifeq ($(BR2_PACKAGE_LIBPCAP),y) +DPDK_DEPENDENCIES += libpcap +endif + +ifeq ($(BR2_SHARED_LIBS),y) +define DPDK_ENABLE_SHARED_LIBS + $(call KCONFIG_ENABLE_OPT,CONFIG_RTE_BUILD_SHARED_LIB,\ + $(@D)/build/.config) +endef + +DPDK_POST_CONFIGURE_HOOKS += DPDK_ENABLE_SHARED_LIBS +endif +
Quoted 9 lines
package/dpdk/Config.in
Quoted 5 lines
package/dpdk/Config.in new file +5
-0+# We're building a kernel module without using the kernel-module infra, +# so we need to tell we want module support in the kernel +ifeq ($(BR2_PACKAGE_DPDK),y) +LINUX_NEEDS_MODULES = y +endifThis is no longer the "right" way of doing this. Just select
BR2_LINUX_NEEDS_MODULESin Config.in.
[...]
My current state is:
config BR2_PACKAGE_DPDK
depends on BR2_PACKAGE_DPDK_ARCH_SUPPORTS
depends on BR2_TOOLCHAIN_USES_GLIBC
depends on BR2_LINUX_NEEDS_MODULES
depends on BR2_TOOLCHAIN_HAS_SYNC_1 &&\
BR2_TOOLCHAIN_HAS_SYNC_2 &&\
BR2_TOOLCHAIN_HAS_SYNC_4 &&\
BR2_TOOLCHAIN_HAS_SYNC_8config BR2_PACKAGE_DPDK_ARCH_SUPPORTS
bool
default y if (BR2_i386 && !BR2_x86_i386 && !BR2_x86_i486 \
&& !BR2_x86_i586 && !BR2_x86_x1000) \
|| BR2_ARM_CPU_ARMV7A || BR2_aarch64 || BR2_aarch64_becomment "dpdk needs a toolchain w/ glibc"
depends on !BR2_TOOLCHAIN_USES_GLIBC
depends on ??
comment "dpdk needs the Linux kernel to be built"
depends on !BR2_LINUX_KERNEL
depends on ??
Jan
Quoted 5 lines
Quoted 1 line
+$(eval $(generic-package))
Other than that, looks good to me.
Thomas
Signature · 4 lines
Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic
PATCH v3 3/3 dpdk: new package
Hello Jan,
Quoted 5 lines · Jan Viktorin
Quoted 3 lines
config
BR2_PACKAGE_DPDK_ARCH_SUPPORTS
bool
default y if ...So, should I move here also the
HAS_SYNCchecks?
Yes, correct. Even though the HAS_SYNC dependencies are not completely/only architecture related, we handle them as such, so it makes sense to have them in the foo_ARCH_SUPPORTS variable.
Quoted 7 lines
Quoted 3 lines
comment "dpdk needs a toolchain w/ glibc"
depends on !BR2_TOOLCHAIN_USES_GLIBC
depends onBR2_TOOLCHAIN_HAS_SYNC_...The conditiion must be "if all dependencies but
BR2_TOOLCHAIN_USES_GLIBCare met", is it right? So, should I put here the HAS_SYNC_*,ARCH_SUPPORTS,BR2_LINUX_KERNELandBR2_LINUX_NEEDS_MODULES?
I think you could do like the on2-8170-libs package, and have a single comment:
comment "dpdk needs a glibc toolchain and a Linux kernel to be built"
depends on BR2_PACKAGE_DPDK_ARCH_SUPPORTS depends on !BR2_LINUX_KERNEL || !BR2_TOOLCHAIN_USES_GLIBC
The idea is that the comment should not be visible if we are on an architecture that anyway does not support DPDK. Otherwise someone say on MIPS will see the comment, enable glibc and Linux kernel, and then will see the comment disappear but not the option to enable dpdk appearing. Which would be confusing, to say the least.
Quoted 5 lines
My current state is:
config
BR2_PACKAGE_DPDK
depends onBR2_PACKAGE_DPDK_ARCH_SUPPORTS
depends onBR2_TOOLCHAIN_USES_GLIBC
depends on BR2_LINUX_KERNEL
Quoted 1 line
depends on
BR2_LINUX_NEEDS_MODULES
This should be a select
Quoted 4 lines
depends on BR2_TOOLCHAIN_HAS_SYNC_1 &&\
BR2_TOOLCHAIN_HAS_SYNC_2 &&\
BR2_TOOLCHAIN_HAS_SYNC_4 &&\
BR2_TOOLCHAIN_HAS_SYNC_8This should go in the BR2_PACKAGE_DPDK_ARCH_SUPPORTS
Quoted 5 lines
config
BR2_PACKAGE_DPDK_ARCH_SUPPORTSbool default y if (BR2_i386 && !BR2_x86_i386 && !BR2_x86_i486 \ && !BR2_x86_i586 && !BR2_x86_x1000) \ || BR2_ARM_CPU_ARMV7A || BR2_aarch64 || BR2_aarch64_be
This can be written in a much more readable way as:
default y if BR2_i386 && !BR2_x86... && !BR2_... default y if BR2_ARM_CPU_ARMV7A default y if BR2_aarch64 ...
Quoted 7 lines
comment "dpdk needs a toolchain w/ glibc"
depends on !BR2_TOOLCHAIN_USES_GLIBC
depends on ??comment "dpdk needs the Linux kernel to be built"
depends on !BR2_LINUX_KERNEL
depends on ??
As said above, only one comment is needed. So here is a proposal:
config BR2_PACKAGE_DPDK_ARCH_SUPPORTS
bool depends on BR2_TOOLCHAIN_HAS_SYNC_1 && \ BR2_TOOLCHAIN_HAS_SYNC_2 && \ BR2_TOOLCHAIN_HAS_SYNC_4 && \ BR2_TOOLCHAIN_HAS_SYNC_8 default y if BR2_i386 && !BR2_x86_i386 && !BR2_x86_i486 \ && !BR2_x86_i586 && !BR2_x86_x1000 default y if BR2_ARM_CPU_ARMV7A default y if BR2_aarch64 || BR2_aarch64_be
config BR2_PACKAGE_DPDK
bool "dpdk"
depends on BR2_PACKAGE_DPDK_ARCH_SUPPORTS
depends on BR2_TOOLCHAIN_USES_GLIBC
depends on BR2_LINUX_KERNEL
select BR2_LINUX_KERNEL_NEEDS_MODULES
help
Blabla
comment "dpdk needs a glibc toolchain and a Linux kernel to be built"
depends on BR2_PACKAGE_DPDK_ARCH_SUPPORTS depends on !BR2_TOOLCHAIN_USES_GLIBC || !BR2_LINUX_KERNEL
Hope this helps,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
v4 cover dpdk: new package
In reply to Jan ViktorinHello,
I've hopefly fixed all the issues. The installation of DPDK examples has been fixed according to T. Petazzoni suggestions. The DPDK *can* install examples but it does it in quite a wierd way (with built garbage and into directories app/ and lib/). Moreover, by overriding the target installation directory, the build fails as it cannot find some SDK libraries.
DPDK 16.04-rc2 is out. The final release should appear in the next 2 weeks.
Regards
Jan
Jan Viktorin (3):
python-ptyprocess: new package
python-pexpect: new package
dpdk: new package
package/Config.in | 3 + package/dpdk/Config.in | 64 ++++++++++++++ package/dpdk/dpdk.hash | 2 + package/dpdk/dpdk.mk | 106 +++++++++++++++++++++++ package/python-pexpect/Config.in | 11 +++ package/python-pexpect/python-pexpect.hash | 4 + package/python-pexpect/python-pexpect.mk | 15 ++++ package/python-ptyprocess/Config.in | 7 ++ package/python-ptyprocess/python-ptyprocess.hash | 4 + package/python-ptyprocess/python-ptyprocess.mk | 14 +++ 10 files changed, 230 insertions(+) create mode 100644 package/dpdk/Config.in create mode 100644 package/dpdk/dpdk.hash create mode 100644 package/dpdk/dpdk.mk create mode 100644 package/python-pexpect/Config.in create mode 100644 package/python-pexpect/python-pexpect.hash create mode 100644 package/python-pexpect/python-pexpect.mk create mode 100644 package/python-ptyprocess/Config.in create mode 100644 package/python-ptyprocess/python-ptyprocess.hash create mode 100644 package/python-ptyprocess/python-ptyprocess.mk
Signature · 1 line
2.7.0
PATCH v4 1/3 python-ptyprocess: new package
v4
* bump to 0.5.1
* source https://pypi.python.org/pypi/ptyprocess
* added hash file
--- package/Config.in | 1 + package/python-ptyprocess/Config.in | 7 +++++++ package/python-ptyprocess/python-ptyprocess.hash | 4 ++++ package/python-ptyprocess/python-ptyprocess.mk | 14 ++++++++++++++ 4 files changed, 26 insertions(+) create mode 100644 package/python-ptyprocess/Config.in create mode 100644 package/python-ptyprocess/python-ptyprocess.hash create mode 100644 package/python-ptyprocess/python-ptyprocess.mk
package/Config.in +1 -0
@@ -689,6 +689,7 @@ menu "External python modules" source "package/python-posix-ipc/Config.in" source "package/python-protobuf/Config.in" source "package/python-psutil/Config.in" + source "package/python-ptyprocess/Config.in" source "package/python-pyasn/Config.in" source "package/python-pyasn-modules/Config.in" source "package/python-pycli/Config.in"
package/python-ptyprocess/Config.in new file +7 -0
@@ -0,0 +1,7 @@ +config BR2_PACKAGE_PYTHON_PTYPROCESS + bool "python-ptyprocess" + help + Launch a subprocess in a pseudo terminal (pty), and interact with + both the process and its pty. + + https://github.com/pexpect/ptyprocess
package/python-ptyprocess/python-ptyprocess.hash new file +4 -0
@@ -0,0 +1,4 @@ +# got from https://pypi.python.org +md5sum 94e537122914cc9ec9c1eadcd36e73a1 ptyprocess-0.5.1.tar.gz +# computed manually +sha256sum 0530ce63a9295bfae7bd06edc02b6aa935619f486f0f1dc0972f516265ee81a6 ptyprocess-0.5.1.tar.gz
package/python-ptyprocess/python-ptyprocess.mk new file +14 -0
@@ -0,0 +1,14 @@ +################################################################################ +# +# python-ptyprocess +# +################################################################################ + +PYTHON_PTYPROCESS_VERSION = 0.5.1 +PYTHON_PTYPROCESS_SITE = https://pypi.python.org/pypi/ptyprocess +PYTHON_PTYPROCESS_SOURCE = ptyprocess-$(PYTHON_PTYPROCESS_VERSION).tar.gz +PYTHON_PTYPROCESS_LICENSE = ISC +PYTHON_PTYPROCESS_LICENSE_FILES = LICENSE +PYTHON_PTYPROCESS_SETUP_TYPE = distutils + +$(eval $(python-package))
Signature · 1 line
2.7.0
PATCH v4 1/3 python-ptyprocess: new package
Quoted 7 lines · On Sun, 27 Mar 2016 03:31:22 +0200 Jan Viktorin <[email protected]> wrote:
v4
* bump to 0.5.1
* source https://pypi.python.org/pypi/ptyprocess
* added hash fileSigned-off-by Jan Viktorin <[email protected]>---
[...]
package/python-ptyprocess/python-ptyprocess.hash line 4
Quoted 10 lines
package/python-ptyprocess/python-ptyprocess.hash new file +4
-0@@ -0,0 +1,4 @@ +# got from https://pypi.python.org +md5sum 94e537122914cc9ec9c1eadcd36e73a1 ptyprocess-0.5.1.tar.gz +# computed manually +sha256sum 0530ce63a9295bfae7bd06edc02b6aa935619f486f0f1dc0972f516265ee81a6 ptyprocess-0.5.1.tar.gz
Should be md5 and sha256 (without sum)...
Quoted 6 lines
package/python-ptyprocess/python-ptyprocess.mk new file +0
-0
package/python-ptyprocess/python-ptyprocess.mk line 8
Quoted 8 lines
package/python-ptyprocess/python-ptyprocess.mk new file +8
-0@@ -0,0 +1,14 @@ +################################################################################ +# +# python-ptyprocess +# +################################################################################ + +PYTHON_PTYPROCESS_VERSION = 0.5.1 +PYTHON_PTYPROCESS_SITE = https://pypi.python.org/pypi/ptyprocess
The URL should be https://pypi.python.org/packages/source/p/ptyprocess.
It seems I accidently didn't test the very last version, sorry. Now, it seems to work.
Quoted 6 lines
package/python-ptyprocess/python-ptyprocess.mk new file +6
-0+PYTHON_PTYPROCESS_SOURCE = ptyprocess-$(PYTHON_PTYPROCESS_VERSION).tar.gz +PYTHON_PTYPROCESS_LICENSE = ISC +PYTHON_PTYPROCESS_LICENSE_FILES = LICENSE +PYTHON_PTYPROCESS_SETUP_TYPE = distutils + +$(eval $(python-package))
PATCH v4 1/3 python-ptyprocess: new package
In reply to Jan ViktorinHello,
Quoted 4 lines · Jan Viktorin
v4
* bump to 0.5.1
* source https://pypi.python.org/pypi/ptyprocess
* added hash file
The changelog should not be in the commit log, but...
Quoted 3 lines
Signed-off-by Jan Viktorin <[email protected]>---
... here.
package/python-ptyprocess/Config.in line 4
Quoted 10 lines
package/python-ptyprocess/Config.in new file +4
-0@@ -0,0 +1,7 @@ +config BR2_PACKAGE_PYTHON_PTYPROCESS + bool "python-ptyprocess" + help + Launch a subprocess in a pseudo terminal (pty), and interact with
Line slightly too long, I've rewrapped.
package/python-ptyprocess/python-ptyprocess.hash line 4
Quoted 13 lines
package/python-ptyprocess/Config.in new file +3
-0+ both the process and its pty. + + https://github.com/pexpect/ptyprocesspackage/python-ptyprocess/python-ptyprocess.hash new file +4
-0@@ -0,0 +1,4 @@ +# got from https://pypi.python.org +md5sum 94e537122914cc9ec9c1eadcd36e73a1 ptyprocess-0.5.1.tar.gz +# computed manually +sha256sum 0530ce63a9295bfae7bd06edc02b6aa935619f486f0f1dc0972f516265ee81a6 ptyprocess-0.5.1.tar.gz
As you noticed yourself, this hash file was wrong.
package/python-ptyprocess/python-ptyprocess.hash
Quoted 2 lines
package/python-ptyprocess/python-ptyprocess.hash new file +2
-0+PYTHON_PTYPROCESS_VERSION = 0.5.1 +PYTHON_PTYPROCESS_SITE = https://pypi.python.org/pypi/ptyprocess
Same for the URL.
I've fixed up those issues and applied. Thanks!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH v4 2/3 python-pexpect: new package
In reply to Jan Viktorinv4
* source https://pypi.python.org/pypi/pexpect
* added hash file
--- package/Config.in | 1 + package/python-pexpect/Config.in | 11 +++++++++++ package/python-pexpect/python-pexpect.hash | 4 ++++ package/python-pexpect/python-pexpect.mk | 15 +++++++++++++++ 4 files changed, 31 insertions(+) create mode 100644 package/python-pexpect/Config.in create mode 100644 package/python-pexpect/python-pexpect.hash create mode 100644 package/python-pexpect/python-pexpect.mk
package/Config.in +1 -0
@@ -686,6 +686,7 @@ menu "External python modules" source "package/python-paho-mqtt/Config.in" source "package/python-pam/Config.in" source "package/python-paramiko/Config.in" + source "package/python-pexpect/Config.in" source "package/python-posix-ipc/Config.in" source "package/python-protobuf/Config.in" source "package/python-psutil/Config.in"
package/python-pexpect/Config.in new file +11 -0
@@ -0,0 +1,11 @@ +config BR2_PACKAGE_PYTHON_PEXPECT + bool "python-pexpect" + select BR2_PACKAGE_PYTHON_PTYPROCESS + help + Pexpect is a pure Python module for spawning child applications; + controlling them; and responding to expected patterns in their + output. Pexpect works like Don Libes? Expect. Pexpect allows your + script to spawn a child application and control it as if a human + were typing commands. + + https://pexpect.readthedocs.org
package/python-pexpect/python-pexpect.hash new file +4 -0
@@ -0,0 +1,4 @@ +# got from https://pypi.python.org +md5sum 056df81e6ca7081f1015b4b147b977b7 +# computed manually: +sha256sum 232795ebcaaf2e120396dbbaa3a129eda51757eeaae1911558f4ef8ee414fc6c pexpect-4.0.1.tar.gz
package/python-pexpect/python-pexpect.mk new file +15 -0
@@ -0,0 +1,15 @@ +################################################################################ +# +# python-pexpect +# +################################################################################ + +PYTHON_PEXPECT_VERSION = 4.0.1 +PYTHON_PEXPECT_SITE = https://pypi.python.org/pypi/pexpect +PYTHON_PEXPECT_SOURCE = pexpect-$(PYTHON_PEXPECT_VERSION).tar.gz +PYTHON_PEXPECT_LICENSE = ISC +PYTHON_PEXPECT_LICENSE_FILES = LICENSE +PYTHON_PEXPECT_SETUP_TYPE = distutils +PYTHON_PEXPECT_DEPENDENCIES = python-ptyprocess + +$(eval $(python-package))
Signature · 1 line
2.7.0
PATCH v4 2/3 python-pexpect: new package
Quoted 6 lines · On Sun, 27 Mar 2016 03:31:23 +0200 Jan Viktorin <[email protected]> wrote:
v4
* source https://pypi.python.org/pypi/pexpect
* added hash fileSigned-off-by Jan Viktorin <[email protected]>---
[...]
package/python-pexpect/python-pexpect.hash line 4
Quoted 10 lines
package/python-pexpect/python-pexpect.hash new file +4
-0@@ -0,0 +1,4 @@ +# got from https://pypi.python.org +md5sum 056df81e6ca7081f1015b4b147b977b7 +# computed manually: +sha256sum 232795ebcaaf2e120396dbbaa3a129eda51757eeaae1911558f4ef8ee414fc6c pexpect-4.0.1.tar.gz
Should be md5 and sha256 (without sum)...
Quoted 6 lines
package/python-pexpect/python-pexpect.mk new file +0
-0
package/python-pexpect/python-pexpect.mk line 8
Quoted 8 lines
package/python-pexpect/python-pexpect.mk new file +8
-0@@ -0,0 +1,15 @@ +################################################################################ +# +# python-pexpect +# +################################################################################ + +PYTHON_PEXPECT_VERSION = 4.0.1 +PYTHON_PEXPECT_SITE = https://pypi.python.org/pypi/pexpect
The URL should be https://pypi.python.org/packages/source/p/pexpect.
Quoted 7 lines
package/python-pexpect/python-pexpect.mk new file +7
-0+PYTHON_PEXPECT_SOURCE = pexpect-$(PYTHON_PEXPECT_VERSION).tar.gz +PYTHON_PEXPECT_LICENSE = ISC +PYTHON_PEXPECT_LICENSE_FILES = LICENSE +PYTHON_PEXPECT_SETUP_TYPE = distutils +PYTHON_PEXPECT_DEPENDENCIES = python-ptyprocess + +$(eval $(python-package))
PATCH v4 2/3 python-pexpect: new package
Quoted 42 lines · Jan Viktorin
Quoted 6 lines · On Sun, 27 Mar 2016 03:31:23 +0200 Jan Viktorin <[email protected]> wrote:
v4
* source https://pypi.python.org/pypi/pexpect
* added hash fileSigned-off-by Jan Viktorin <[email protected]>---
[...]
package/python-pexpect/python-pexpect.hash line 4
Quoted 10 lines
package/python-pexpect/python-pexpect.hash new file +4
-0@@ -0,0 +1,4 @@ +# got from https://pypi.python.org +md5sum 056df81e6ca7081f1015b4b147b977b7 +# computed manually: +sha256sum 232795ebcaaf2e120396dbbaa3a129eda51757eeaae1911558f4ef8ee414fc6c pexpect-4.0.1.tar.gzShould be md5 and sha256 (without sum)...
Quoted 6 lines
package/python-pexpect/python-pexpect.mk new file +0
-0package/python-pexpect/python-pexpect.mk line 8
Quoted 8 lines
package/python-pexpect/python-pexpect.mk new file +8
-0@@ -0,0 +1,15 @@ +################################################################################ +# +# python-pexpect +# +################################################################################ + +PYTHON_PEXPECT_VERSION = 4.0.1 +PYTHON_PEXPECT_SITE = https://pypi.python.org/pypi/pexpectThe URL should be https://pypi.python.org/packages/source/p/pexpect.
Quoted 5 lines
package/python-pexpect/python-pexpect.mk line 13
Quoted 5 lines
package/python-pexpect/python-pexpect.mk new file +5
-0+PYTHON_PEXPECT_SOURCE = pexpect-$(PYTHON_PEXPECT_VERSION).tar.gz +PYTHON_PEXPECT_LICENSE = ISC +PYTHON_PEXPECT_LICENSE_FILES = LICENSE +PYTHON_PEXPECT_SETUP_TYPE = distutils +PYTHON_PEXPECT_DEPENDENCIES = python-ptyprocess
drop this build-time dependency
Resend v5 with all fixes and add my
to both python patches.
Thanks.
Yegor
Quoted 2 lines
Quoted 2 lines
package/python-pexpect/python-pexpect.mk new file +2
-0+ +$(eval $(python-package))
PATCH v4 2/3 python-pexpect: new package
In reply to Jan ViktorinHello,
Quoted 3 lines · Jan Viktorin
v4
* source https://pypi.python.org/pypi/pexpect
* added hash file
The changelog should not be part of the commit, but should be ...
Quoted 3 lines
Signed-off-by Jan Viktorin <[email protected]>---
... here.
Quoted 6 lines
package/python-pexpect/Config.in new file +0
-0
package/python-pexpect/Config.in line 9
Quoted 9 lines
package/python-pexpect/Config.in new file +9
-0@@ -0,0 +1,11 @@ +config BR2_PACKAGE_PYTHON_PEXPECT + bool "python-pexpect" + select BR2_PACKAGE_PYTHON_PTYPROCESS + help + Pexpect is a pure Python module for spawning child applications; + controlling them; and responding to expected patterns in their + output. Pexpect works like Don Libes? Expect. Pexpect allows your + script to spawn a child application and control it as if a human + were typing commands.
Same thing: lines slightly too long.
package/python-pexpect/python-pexpect.hash line 2
Quoted 8 lines
package/python-pexpect/python-pexpect.hash new file +2
-0@@ -0,0 +1,4 @@ +# got from https://pypi.python.org +md5sum 056df81e6ca7081f1015b4b147b977b7
Not even a file name here.
package/python-pexpect/python-pexpect.hash line 4
Quoted 2 lines
package/python-pexpect/python-pexpect.hash new file +2
-0+# computed manually: +sha256sum 232795ebcaaf2e120396dbbaa3a129eda51757eeaae1911558f4ef8ee414fc6c pexpect-4.0.1.tar.gz
I've fixed up the hash file.
package/python-pexpect/python-pexpect.hash
Quoted 2 lines
package/python-pexpect/python-pexpect.hash new file +2
-0+PYTHON_PEXPECT_VERSION = 4.0.1 +PYTHON_PEXPECT_SITE = https://pypi.python.org/pypi/pexpect
And the _SITE variable.
package/python-pexpect/python-pexpect.hash
Quoted 5 lines
package/python-pexpect/python-pexpect.hash new file +5
-0+PYTHON_PEXPECT_SOURCE = pexpect-$(PYTHON_PEXPECT_VERSION).tar.gz +PYTHON_PEXPECT_LICENSE = ISC +PYTHON_PEXPECT_LICENSE_FILES = LICENSE +PYTHON_PEXPECT_SETUP_TYPE = distutils +PYTHON_PEXPECT_DEPENDENCIES = python-ptyprocess
And removed this dependency: it's only a run-time dependency, so it only needs to be in the Config.in file.
Applied with those issues fixed, thanks!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH v4 3/3 dpdk: new package
In reply to Jan ViktorinThis patch introduces support of the DPDK library (www.dpdk.org) into Buildroot. DPDK is a library for high-speed packet sending/receiving while bypassing the Linux Kernel. It allows to reach a high throughput for 10-100 Gbps networks on the x86 platform.
The package compiles and installs DPDK libraries on the target and staging and allows to compile other applications depending on the DPDK library. It can also install some basic tools the DPDK provides (testpmd, python scripts, test suite).
The patch assumes DPDK 16.04-rc2. This version contains support for the ARM architecture. The ARM ports can be tested by
qemu_aarch64_virt_defconfig
qemu_arm_vexpress_defconfig
The included hash was calculated locally by downloading the tar.gz archives by hand.
There are unfortunately some pitfalls:
* it may require to enable PCI, MSIX, UIO in the Linux Kernel (some defconfigs does not include as default and it is platform dependent as ARMv7 almost does not use PCI)
* when building PCAP PMD driver, the libpcap is required (partially fixed as suggested by Arnout)
* some tools the DPDK provides depend on Python(2) so the user has to enable it to install those
---
v2: (mostly suggestions by Arnout)
* simplified Config.in - avoid version, source and config selection
* improved dependency on libpcap
* user python scripts are included if python package is enabled
* installing of tests includes autotest*.py scripts (we do not care about the python here, assuming the user will install it manually when testing)
* minor coding style fixes
* depends on python-pexpect package
* using version 2.2.0-rc3
v3
* bump to version 16.04-rc1
* utilizing the new install syntax of DPDK
* fixed line wrapping
* testpmd is now always installed (no option for this)
* fixed python dependencies (T. Petazzoni)
* supporting i686+ architectures (T. Petazzoni)
* dropped PPC support for now
* utilizing KCONFIG_ENABLE_OPT macro
* support for build & install of examples (ugly code)
* build with MAKE instead of MAKE1 seems OK now
* dropped COMBINE_LIBS (no more in DPDK)
* added HAS_SYNC_x
* few random fixes
v4 (suggestions by T. Petazzoni)
* bump to version 16.04-rc2
* fixed indentation in Config.in
* fixed depends in Config.in
* handling kernel modules by BR2_LINUX_NEEDS_MODULES
* simplified installation of examples
--- package/Config.in | 1 + package/dpdk/Config.in | 64 +++++++++++++++++++++++++++++ package/dpdk/dpdk.hash | 2 + package/dpdk/dpdk.mk | 106 +++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 173 insertions(+) create mode 100644 package/dpdk/Config.in create mode 100644 package/dpdk/dpdk.hash create mode 100644 package/dpdk/dpdk.mk
package/Config.in +1 -0
@@ -1097,6 +1097,7 @@ menu "Networking" source "package/cgic/Config.in" source "package/cppzmq/Config.in" source "package/czmq/Config.in" + source "package/dpdk/Config.in" source "package/filemq/Config.in" source "package/flickcurl/Config.in" source "package/fmlib/Config.in"
package/dpdk/Config.in new file +64 -0
64 lines not on this page · raw message
package/dpdk/dpdk.hash new file +2 -0
@@ -0,0 +1,2 @@ +# Locally calculated +sha256 fdd96e8f3ae9506642c8cd961422960360abbe9d1ba28323704c93a3c065ba6d dpdk-16.04-rc2.tar.gz
package/dpdk/dpdk.mk new file +106 -0
106 lines not on this page · raw message
Signature · 1 line
2.7.0
PATCH v4 3/3 dpdk: new package
Quoted 5 lines · On Sun, 27 Mar 2016 03:31:24 +0200 Jan Viktorin <[email protected]> wrote:
This patch introduces support of the DPDK library (www.dpdk.org) into Buildroot. DPDK is a library for high-speed packet sending/receiving while bypassing the Linux Kernel. It allows to reach a high throughput for 10-100 Gbps networks on the x86 platform.
[...]
package/dpdk/dpdk.mk line 33
Quoted 6 lines
package/dpdk/dpdk.mk new file +6
-0+ +# We're building a kernel module without using the kernel-module infra, +# so we need to tell we want module support in the kernel +ifeq ($(BR2_PACKAGE_DPDK),y) +LINUX_NEEDS_MODULES = y +endif
Ups, I forgot to delete this LINUX_NEEDS_MODULES (moved to Config.in already).
Jan
Quoted 2 lines
(quoted diff) +2
-0+ +DPDK_CONFIG = $(call qstrip,$(BR2_PACKAGE_DPDK_CONFIG))
[...]
PATCH v4 3/3 dpdk: new package
In reply to Jan ViktorinHello,
Quoted 8 lines · Jan Viktorin
The included hash was calculated locally by downloading the tar.gz archives by hand.
There are unfortunately some pitfalls:
* it may require to enable PCI, MSIX, UIO in the Linux Kernel (some defconfigs does not include as default and it is platform dependent as ARMv7 almost does not use PCI)
I have enabled PCI_MSI=y and UIO=y in my kernel configuration, and still, I don't have any .ko file installed in my target. Is this expected?
Quoted 29 lines
package/dpdk/Config.in new file +23
-0@@ -0,0 +1,64 @@ +config BR2_PACKAGE_DPDK + bool "dpdk" + depends on BR2_PACKAGE_DPDK_ARCH_SUPPORTS + depends on BR2_TOOLCHAIN_USES_GLIBC + depends on BR2_LINUX_KERNEL + select BR2_LINUX_NEEDS_MODULES + help + DPDK is a set of libraries and drivers for fast packet processing. It + was designed to run on any processors, however, Intel x86 has been + the first CPU to be supported. Ports for other CPUs like IBM Power 8 + and ARM are under progress. It runs mostly in Linux userland. A + FreeBSD port is now available for a subset of DPDK features. + + Notes: + * To build the included Linux Kernel drivers, it is necessary to + enable CONFIG_PCI_MSI, CONFIG_UIO. + * To build the PCAP PMD properly, you need to enable the libpcap + manually. + * You may need to install the python2 interpreter if you want to use + scripts dpdk_nic_bind.py and cpu_layout.py + + http://www.dpdk.org/ +
package/dpdk/Config.in line 33
Quoted 10 lines
package/dpdk/Config.in new file +10
-0+config BR2_PACKAGE_DPDK_ARCH_SUPPORTS + bool + depends on BR2_TOOLCHAIN_HAS_SYNC_1 &&\ + BR2_TOOLCHAIN_HAS_SYNC_2 &&\ + BR2_TOOLCHAIN_HAS_SYNC_4 &&\ + BR2_TOOLCHAIN_HAS_SYNC_8 + default y if (BR2_i386 && !BR2_x86_i386 && !BR2_x86_i486 \ + && !BR2_x86_i586 && !BR2_x86_x1000) + default y if BR2_ARM_CPU_ARMV7A + default y if BR2_aarch64 || BR2_aarch64_be
What about BR2_x86_64 ?
package/dpdk/Config.in line 37
Quoted 4 lines
package/dpdk/Config.in new file +4
-0+ +comment "dpdk needs a glibc toolchain and a Linux Kernel to be built" + depends on BR2_PACKAGE_DPDK_ARCH_SUPPORTS + depends on !BR2_TOOLCHAIN_USES_GLIBC || !BR2_LINUX_KERNEL
The BR2_PACKAGE_DPDK_ARCH_SUPPORTS option and the comment should go before the BR2_PACKAGE_DPDK so that the dpdk sub-options can be properly indented by menuconfig.
Quoted 14 lines
package/dpdk/Config.in new file +14
-0+if BR2_PACKAGE_DPDK + +config BR2_PACKAGE_DPDK_CONFIG + string "Configuration" + default "i686-native-linuxapp-gcc" \ + if BR2_x86_i686 + default "x86_64-native-linuxapp-gcc" \ + if BR2_x86_64 + default "arm-armv7a-linuxapp-gcc" \ + if BR2_ARM_CPU_ARMV7A + default "arm64-armv8a-linuxapp-gcc" \ + if BR2_aarch64 || BR2_aarch64_be + +config BR2_PACKAGE_DPDK_TEST
package/dpdk/Config.in line 62
Quoted 10 lines
package/dpdk/Config.in new file +10
-0+ bool "Install tests suite" + select BR2_PACKAGE_PYTHON_PEXPECT if BR2_PACKAGE_PYTHON + help + Install all DPDK tests. If you want to run the tests by the included + autotest.py script you need to enable python manually. + +config BR2_PACKAGE_DPDK_EXAMPLES + bool "Build & install examples" + help + Build and install all examples selected by the current configuration.
Please remove this option and the example build/installation. It is too complicated for now. Upstream should create a proper build/installation process for these. In the mean time, let's merge a dpdk package that does not bother building/installing the examples.
package/dpdk/dpdk.mk line 7
Quoted 13 lines
package/dpdk/dpdk.mk new file +7
-0@@ -0,0 +1,106 @@ +################################################################################ +# +# dpdk +# +################################################################################ + +DPDK_VERSION = 16.04-rc2
Please update to the latest 16.04 version.
Quoted 16 lines
package/dpdk/dpdk.mk new file +16
-0+DPDK_SITE = http://dpdk.org/browse/dpdk/snapshot + +DPDK_LICENSE = BSD-2c (core), GPLv2+ (Linux drivers) +DPDK_LICENSE_FILES = GNUmakefile LICENSE.GPL +DPDK_INSTALL_STAGING = YES + +DPDK_DEPENDENCIES += linux + +ifeq ($(BR2_PACKAGE_LIBPCAP),y) +DPDK_DEPENDENCIES += libpcap +endif + +ifeq ($(BR2_SHARED_LIBS),y) +define DPDK_ENABLE_SHARED_LIBS + $(call KCONFIG_ENABLE_OPT,CONFIG_RTE_BUILD_SHARED_LIB,\ + $(@D)/build/.config)
package/dpdk/dpdk.mk line 33
Quoted 10 lines
package/dpdk/dpdk.mk new file +10
-0+endef + +DPDK_POST_CONFIGURE_HOOKS += DPDK_ENABLE_SHARED_LIBS +endif + +# We're building a kernel module without using the kernel-module infra, +# so we need to tell we want module support in the kernel +ifeq ($(BR2_PACKAGE_DPDK),y) +LINUX_NEEDS_MODULES = y +endif
This is no longer needed since you are selectingBR2_LINUX_NEEDS_MODULES.
Quoted 30 lines
package/dpdk/dpdk.mk new file +30
-0+DPDK_CONFIG = $(call qstrip,$(BR2_PACKAGE_DPDK_CONFIG)) + +ifeq ($(BR2_PACKAGE_DPDK_EXAMPLES),y) +# Build of DPDK examples is not very straight-forward. It requires to have +# the SDK and runtime installed on same place to reference it by RTE_SDK. +# We place it locally in the build directory. +define DPDK_BUILD_EXAMPLES + $(MAKE) -C $(@D) DESTDIR=$(@D)/examples-sdk \ + CROSS=$(TARGET_CROSS) install-sdk install-runtime + $(MAKE) -C $(@D) RTE_KERNELDIR=$(LINUX_DIR) CROSS=$(TARGET_CROSS) \ + RTE_SDK=$(@D)/examples-sdk/usr/local/share/dpdk \ + T=$(DPDK_CONFIG) examples +endef + +DPDK_EXAMPLES_PATH = $(@D)/examples-sdk/usr/local/share/dpdk/examples + +# Installation of examples is tricky in DPDK so we do it explicitly here. +# As the binaries and libraries do not have a single or regular location +# where to find them after build, we search for them by find. +define DPDK_INSTALL_EXAMPLES + for f in `find $(DPDK_EXAMPLES_PATH) -executable -type f \ + -path '*/lib/*.so*'`; do \ + $(INSTALL) -m 0755 -D $$f \ + $(TARGET_DIR)/usr/lib/`basename $$f` || exit 1;\ + done + for f in `find $(DPDK_EXAMPLES_PATH) -executable -type f \ + -path '*/app/*'`; do \ + $(INSTALL) -m 0755 -D $$f \ + $(TARGET_DIR)/usr/bin/`basename $$f` || exit 1;\ + done
package/dpdk/dpdk.mk line 74
Quoted 10 lines
package/dpdk/dpdk.mk new file +10
-0+endef + +# Build of the power example is broken (at least for 16.04). +define DPDK_DISABLE_POWER + $(call KCONFIG_DISABLE_OPT,CONFIG_RTE_LIBRTE_POWER,\ + $(@D)/build/.config) +endef + +DPDK_POST_CONFIGURE_HOOKS += DPDK_DISABLE_POWER +endif
Please remove this entire ifeq ... endif block.
package/dpdk/dpdk.mk line 82
Quoted 8 lines
package/dpdk/dpdk.mk new file +8
-0+ +define DPDK_CONFIGURE_CMDS + $(MAKE) -C $(@D) T=$(DPDK_CONFIG) RTE_KERNELDIR=$(LINUX_DIR) \ + CROSS=$(TARGET_CROSS) config +endef + +define DPDK_BUILD_CMDS + $(MAKE) -C $(@D) RTE_KERNELDIR=$(LINUX_DIR) CROSS=$(TARGET_CROSS)
When the architecture is ARMv7, please pass:
CPU_FLAGS=
Otherwise, the dpdk build system passes -mfloat-abi=softfp, which makes the build fail when the selected ABI is EABIhf. And please report the bug upstream: the dpdk build system should not make assumptions on the selected ARM ABI.
package/dpdk/dpdk.mk line 83
Quoted 1 line
package/dpdk/dpdk.mk new file +1
-0+ $(DPDK_BUILD_EXAMPLES)
This can be removed.
package/dpdk/dpdk.mk line 93
Quoted 10 lines
package/dpdk/dpdk.mk new file +10
-0+endef + +define DPDK_INSTALL_STAGING_CMDS + $(MAKE) -C $(@D) DESTDIR=$(STAGING_DIR) prefix=/usr \ + CROSS=$(TARGET_CROSS) install-sdk +endef + +ifeq ($(BR2_PACKAGE_DPDK_TEST),y) +define DPDK_INSTALL_TARGET_TEST + $(INSTALL) -m 0755 -d $(TARGET_DIR)/usr/dpdk
mkdir -p
package/dpdk/dpdk.mk line 94
Quoted 1 line
package/dpdk/dpdk.mk new file +1
-0+ $(INSTALL) -m 0755 -D $(@D)/build/app/test $(TARGET_DIR)/usr/dpdk
Full destination path:
$(INSTALL) -m 0755 -D $(@D)/build/app/test $(TARGET_DIR)/usr/dpdk/test
package/dpdk/dpdk.mk line 95
Quoted 1 line
package/dpdk/dpdk.mk new file +1
-0+ $(INSTALL) -m 0755 -D $(@D)/app/test/*.py $(TARGET_DIR)/usr/dpdk
To copy multiple files:
cp -dpfr $(@D)/app/test/*.py $(TARGET_DIR)/usr/dpdk
package/dpdk/dpdk.mk line 103
Quoted 5 lines
package/dpdk/dpdk.mk new file +5
-0+define DPDK_INSTALL_TARGET_CMDS + $(MAKE) -C $(@D) DESTDIR=$(TARGET_DIR) prefix=/usr \ + CROSS=$(TARGET_CROSS) install-runtime + $(DPDK_INSTALL_TARGET_TEST) + $(DPDK_INSTALL_EXAMPLES)
Remove this one.
Can you fix those issues and resend?
Thanks!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH v4 3/3 dpdk: new package
Quoted 1 line · On Fri, 15 Apr 2016 23:52:03 +0200 Thomas Petazzoni…
Hello,
Dear Thomas,
thanks a lot for your help! I've fixed those...
Quoted 8 lines
Quoted 4 lines
* it may require to enable PCI, MSIX, UIO in the Linux Kernel (some defconfigs does not include as default and it is platform dependent as ARMv7 almost does not use PCI)
I have enabled PCI_MSI=y and UIO=y in my kernel configuration, and still, I don't have any .ko file installed in my target. Is this expected?
Of course, you are right. They are built but not installed. Fixed.
Quoted 1 line
[...]
Quoted 6 lines
package/dpdk/dpdk.mk line 82
Quoted 3 lines
package/dpdk/dpdk.mk new file +3
-0+ +define DPDK_BUILD_CMDS + $(MAKE) -C $(@D) RTE_KERNELDIR=$(LINUX_DIR) CROSS=$(TARGET_CROSS)When the architecture is ARMv7, please pass:
Quoted 6 lines
CPU_FLAGS=
Otherwise, the dpdk build system passes -mfloat-abi=softfp, which makes the build fail when the selected ABI is EABIhf. And please report the bug upstream: the dpdk build system should not make assumptions on the selected ARM ABI.
Well, this leads to some hardcoded check of architecture into the dpdk.mk. I don't like such approach. Would you instead accept the following (temporary) patch into Buildroot as a solution for this?
http://dpdk.org/ml/archives/dev/2016-April/037577.html
I will remove it with the next DPDK release (when it's in the mainline). I've tested and it builds successfully for both ABI and EABIhf.
Quoted 1 line
[...]
Quoted 2 lines
Can you fix those issues and resend?
Sure, I will resend after I solve the ARM ABI issue.
Quoted 4 lines
Thanks!
Thomas
Regards
Jan
Signature · 4 lines
Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic
PATCH v4 3/3 dpdk: new package
Hello,
Quoted 5 lines · Jan Viktorin
Quoted 3 lines
I have enabled PCI_MSI=y and UIO=y in my kernel configuration, and still, I don't have any .ko file installed in my target. Is this expected?
Of course, you are right. They are built but not installed. Fixed.
Good, thanks!
Quoted 11 lines
Quoted 8 lines
When the architecture is ARMv7, please pass:
CPU_FLAGS=
Otherwise, the dpdk build system passes -mfloat-abi=softfp, which makes the build fail when the selected ABI is EABIhf. And please report the bug upstream: the dpdk build system should not make assumptions on the selected ARM ABI.
Well, this leads to some hardcoded check of architecture into the dpdk.mk. I don't like such approach.
Well, I don't see what's the problem with that really, but...
Quoted 4 lines
Would you instead accept the
following (temporary) patch into Buildroot as a solution for this?
... if such a patch gets accepted upstream, then I'm fine with carrying the patch in Buildroot in the mean time.
Quoted 3 lines
Quoted 1 line
Can you fix those issues and resend?
Sure, I will resend after I solve the ARM ABI issue.
Well, you solved it it seems, right? :-)
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH v5 1/1 dpdk: new package
In reply to Jan ViktorinThis patch introduces support of the DPDK library (www.dpdk.org) into Buildroot. DPDK is a library for high-speed packet sending/receiving while bypassing the Linux Kernel. It allows to reach a high throughput for 10-100 Gbps networks on the x86 platform.
The package compiles and installs DPDK libraries on the target and staging and allows to compile other applications depending on the DPDK library. It can also install some basic tools the DPDK provides (testpmd, python scripts, test suite).
The patch assumes DPDK 16.04. This version contains support for the ARM architecture. The ARM ports can be tested by
qemu_aarch64_virt_defconfig
qemu_arm_vexpress_defconfig
The included hash was calculated locally by downloading the tar.gz archives by hand.
There are unfortunately some pitfalls:
* it may require to enable PCI, MSIX, UIO in the Linux Kernel (some defconfigs does not include as default and it is platform dependent as ARMv7 almost does not use PCI)
* when building PCAP PMD driver, the libpcap is required (partially fixed as suggested by Arnout)
* some tools the DPDK provides depend on Python(2) so the user has to enable it to install those
---
v2: (mostly suggestions by Arnout)
* simplified Config.in - avoid version, source and config selection
* improved dependency on libpcap
* user python scripts are included if python package is enabled
* installing of tests includes autotest*.py scripts (we do not care about the python here, assuming the user will install it manually when testing)
* minor coding style fixes
* depends on python-pexpect package
* using version 2.2.0-rc3
v3
* bump to version 16.04-rc1
* utilizing the new install syntax of DPDK
* fixed line wrapping
* testpmd is now always installed (no option for this)
* fixed python dependencies (T. Petazzoni)
* supporting i686+ architectures (T. Petazzoni)
* dropped PPC support for now
* utilizing KCONFIG_ENABLE_OPT macro
* support for build & install of examples (ugly code)
* build with MAKE instead of MAKE1 seems OK now
* dropped COMBINE_LIBS (no more in DPDK)
* added HAS_SYNC_x
* few random fixes
v4 (suggestions by T. Petazzoni)
* bump to version 16.04-rc2
* fixed indentation in Config.in
* fixed depends in Config.in
* handling kernel modules by BR2_LINUX_NEEDS_MODULES
* simplified installation of examples
v5
* bump to version 16.04
* dropped (forgotten) LINUX_NEEDS_MODULES=y from mk
* reordered Config.in (T. Petazzoni)
* added forgotten BR2_x86_64 (T. Petazzoni)
* dropped support for examples (T. Petazzoni)
* fix install of kernel modules (T. Petazzoni)
* patch ARM ABI enforcing (T. Petazzoni)
* minor install fixes (T. Petazzoni)
--- package/Config.in | 1 + ...01-mk-do-not-enforce-any-specific-ARM-ABI.patch | 31 +++++++++++ package/dpdk/Config.in | 60 ++++++++++++++++++++++ package/dpdk/dpdk.hash | 2 + package/dpdk/dpdk.mk | 60 ++++++++++++++++++++++ 5 files changed, 154 insertions(+) create mode 100644 package/dpdk/0001-mk-do-not-enforce-any-specific-ARM-ABI.patch create mode 100644 package/dpdk/Config.in create mode 100644 package/dpdk/dpdk.hash create mode 100644 package/dpdk/dpdk.mk
package/Config.in +1 -0
@@ -1102,6 +1102,7 @@ menu "Networking" source "package/cgic/Config.in" source "package/cppzmq/Config.in" source "package/czmq/Config.in" + source "package/dpdk/Config.in" source "package/filemq/Config.in" source "package/flickcurl/Config.in" source "package/fmlib/Config.in"
package/dpdk/0001-mk-do-not-enforce-any-specific-ARM-ABI.patch new file +31 -0
@@ -0,0 +1,31 @@ +From 524dc6e45487737f1465e7edade840613f083c8f Mon Sep 17 00:00:00 2001 +From: Jan Viktorin <[email protected]> +Date: Sat, 16 Apr 2016 00:11:18 +0200 +Subject: [PATCH] mk: do not enforce any specific ARM ABI + +The dpdk build system passes -mfloat-abi=softfp, which makes the build fail +when the selected ABI is EABIhf. The dpdk build system should not make +assumptions on the selected ARM ABI. + +Signed-off-by: Jan Viktorin <[email protected]> +Reported-by: Thomas Petazzoni <[email protected]> +--- + mk/machine/armv7a/rte.vars.mk | 2 -- + 1 file changed, 2 deletions(-) + +diff --git a/mk/machine/armv7a/rte.vars.mk b/mk/machine/armv7a/rte.vars.mk +index abdb15e..36fa3de 100644 +--- a/mk/machine/armv7a/rte.vars.mk ++++ b/mk/machine/armv7a/rte.vars.mk +@@ -54,8 +54,6 @@ + # CPU_LDFLAGS = + # CPU_ASFLAGS = + +-CPU_CFLAGS += -mfloat-abi=softfp +- + MACHINE_CFLAGS += -march=armv7-a + + ifdef CONFIG_RTE_ARCH_ARM_TUNE +-- +2.8.0 +
package/dpdk/Config.in new file +60 -0
60 lines not on this page · raw message
package/dpdk/dpdk.hash new file +2 -0
@@ -0,0 +1,2 @@ +# Locally calculated +sha256 d631495bc6e8d4c4aec72999ac03c3ce213bb996cb88f3bf14bb980dad1d3f7b dpdk-16.04.tar.gz
package/dpdk/dpdk.mk new file +60 -0
60 lines not on this page · raw message
Signature · 1 line
2.8.0
PATCH v5 1/1 dpdk: new package
Hello,
Quoted 25 lines · Jan Viktorin
This patch introduces support of the DPDK library (www.dpdk.org) into Buildroot. DPDK is a library for high-speed packet sending/receiving while bypassing the Linux Kernel. It allows to reach a high throughput for 10-100 Gbps networks on the x86 platform.
The package compiles and installs DPDK libraries on the target and staging and allows to compile other applications depending on the DPDK library. It can also install some basic tools the DPDK provides (testpmd, python scripts, test suite).
The patch assumes DPDK 16.04. This version contains support for the ARM architecture. The ARM ports can be tested by
qemu_aarch64_virt_defconfig
qemu_arm_vexpress_defconfigThe included hash was calculated locally by downloading the tar.gz archives by hand.
There are unfortunately some pitfalls:
* it may require to enable PCI, MSIX, UIO in the Linux Kernel (some defconfigs does not include as default and it is platform dependent as ARMv7 almost does not use PCI)
Quoted 7 lines
* when building PCAP PMD driver, the libpcap is required (partially fixed as suggested by Arnout)
* some tools the DPDK provides depend on Python(2) so the user has to enable it to install those
Signed-off-by Jan Viktorin <[email protected]>
Thanks for this new iteration. Unfortunately, it still doesn't install any kernel module to my system. At install time, your addition of the install-kmod target simply does:
make[3]: Nothing to be done for 'install-kmod'.
Moreover, are you sure having a Linux kernel already built is always necessary? My understanding is that while DPDK has its own kernel modules, it can also rely on the kernel generic uio_pci_generic module. In this case, DPDK only needs to build userspace components, and no kernel component, which would make the dependency on Linux optional.
From the DPDK documentation: "To run any DPDK application, a suitable uio module can be loaded into the running kernel. In many cases, the standard uio_pci_generic module included in the Linux kernel can provide the uio capability.".
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH v5 1/1 dpdk: new package
Hello Thomas,
what configuration do you use?
In general, I cannot say? we are always fine with the in-kernel modules. There are configurations of DPDK that build certain drivers. Of course, DPDK community would like to have no out-of-tree drivers. Some devices require a certain driver.
The x86 configuration builds drivers. The armv7 one doesn't (there are no useful drivers for this purpose).
A user may serve its own configuration of DPDK where a kernel driver is selected and thus, the user would expect it to be built and installed.
It seems that in the future the in-kernel vfio is the way to? go.
Jan?Viktorin
RehiveTech
Sent?from?a?mobile?device
? P?vodn? zpr?va ?
Od: Thomas Petazzoni
Odesl?no: ned?le, 17. dubna 2016 16:38
Komu: Jan Viktorin
Kopie: buildroot at buildroot.org
P?edm?t: Re: [Buildroot] [PATCH v5] dpdk: new package
Hello,
Quoted 25 lines · Jan Viktorin
This patch introduces support of the DPDK library (www.dpdk.org) into Buildroot. DPDK is a library for high-speed packet sending/receiving while bypassing the Linux Kernel. It allows to reach a high throughput for 10-100 Gbps networks on the x86 platform.
The package compiles and installs DPDK libraries on the target and staging and allows to compile other applications depending on the DPDK library. It can also install some basic tools the DPDK provides (testpmd, python scripts, test suite).
The patch assumes DPDK 16.04. This version contains support for the ARM architecture. The ARM ports can be tested by
qemu_aarch64_virt_defconfigqemu_arm_vexpress_defconfigThe included hash was calculated locally by downloading the tar.gz archives by hand.
There are unfortunately some pitfalls:
* it may require to enable PCI, MSIX, UIO in the Linux Kernel (some defconfigs does not include as default and it is platform dependent as ARMv7 almost does not use PCI)
Quoted 7 lines
* when building PCAP PMD driver, the libpcap is required (partially fixed as suggested by Arnout)
* some tools the DPDK provides depend on Python(2) so the user has to enable it to install those
Signed-off-by Jan Viktorin <[email protected]>
Thanks for this new iteration. Unfortunately, it still doesn't install any kernel module to my system. At install time, your addition of the install-kmod target simply does:
make[3]: Nothing to be done for 'install-kmod'.
Moreover, are you sure having a Linux kernel already built is always necessary? My understanding is that while DPDK has its own kernel modules, it can also rely on the kernel generic uio_pci_generic module. In this case, DPDK only needs to build userspace components, and no kernel component, which would make the dependency on Linux optional.
From the DPDK documentation: "To run any DPDK application, a suitable uio module can be loaded into the running kernel. In many cases, the standard uio_pci_generic module included in the Linux kernel can provide the uio capability.".
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH v5 1/1 dpdk: new package
Hello,
Quoted 1 line · Jan Viktorin
what configuration do you use?
BR2_arm=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/br-arm-full-2016.02-3-g762b7c9.tar.bz2" BR2_TOOLCHAIN_EXTERNAL_GCC_4_7=y
BR2_TOOLCHAIN_EXTERNAL_HEADERS_3_10=y
BR2_TOOLCHAIN_EXTERNAL_LOCALE=y
# BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS_DEBUG is not set
BR2_TOOLCHAIN_EXTERNAL_INET_RPC=y
BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_INIT_NONE=y
BR2_SYSTEM_BIN_SH_NONE=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.5"
BR2_LINUX_KERNEL_DEFCONFIG="mvebu_v7"
# BR2_PACKAGE_BUSYBOX is not set
BR2_PACKAGE_DPDK=y
# BR2_TARGET_ROOTFS_TAR is not set
Before starting the build, I do "make linux-menuconfig", and enable CONFIG_UIO in the kernel configuration.
Quoted 7 lines
In general, I cannot say? we are always fine with the in-kernel modules. There are configurations of DPDK that build certain drivers. Of course, DPDK community would like to have no out-of-tree drivers. Some devices require a certain driver.
The x86 configuration builds drivers. The armv7 one doesn't (there are no useful drivers for this purpose).
Then IMO the dependency on the Linux kernel should be optional.
Quoted 3 lines
A user may serve its own configuration of DPDK where a kernel driver is selected and thus, the user would expect it to be built and installed.
Right. But if the default configuration doesn't require the kernel to be built, we probably shouldn't require it as well.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH v5 1/1 dpdk: new package
Well, your config is for ARMv7 so no kmods are built because all current drivers require PCI which is hardly to see on this platform (I know just about Armada).
Ok. I don't know what would be the use case for dropping dependency on the kernel. Building just the rootfs without the kernel?
That means to check whether the kernel is enabled. And if it is then to enable building of the DPDK kernel modules. Right?
This can be done but I am afraid I have to disable certain modules by name from the current configuration. This is not very generic (consider adding a new out-of-tree kernel module or removing an obsolete one from the DPDK, custom DPDK tree with third party modules) but there are only few of them so it might be a working solution. I will check if there is a more generic way but I don't think so. ?
Jan?Viktorin
RehiveTech?
Sent?from?a?mobile?device
? P?vodn? zpr?va ?
Od: Thomas Petazzoni
Odesl?no: ned?le, 17. dubna 2016 21:35
Komu: Jan Viktorin
Kopie: buildroot at buildroot.org
P?edm?t: Re: [Buildroot] [PATCH v5] dpdk: new package
Hello,
Quoted 1 line · Jan Viktorin
what configuration do you use?
BR2_arm=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/br-arm-full-2016.02-3-g762b7c9.tar.bz2" BR2_TOOLCHAIN_EXTERNAL_GCC_4_7=y
BR2_TOOLCHAIN_EXTERNAL_HEADERS_3_10=y
BR2_TOOLCHAIN_EXTERNAL_LOCALE=y
# BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS_DEBUG is not set
BR2_TOOLCHAIN_EXTERNAL_INET_RPC=y
BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_INIT_NONE=y
BR2_SYSTEM_BIN_SH_NONE=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.5"
BR2_LINUX_KERNEL_DEFCONFIG="mvebu_v7"
# BR2_PACKAGE_BUSYBOX is not set
BR2_PACKAGE_DPDK=y
# BR2_TARGET_ROOTFS_TAR is not set
Before starting the build, I do "make linux-menuconfig", and enable CONFIG_UIO in the kernel configuration.
Quoted 7 lines
In general, I cannot say? we are always fine with the in-kernel modules. There are configurations of DPDK that build certain drivers. Of course, DPDK community would like to have no out-of-tree drivers. Some devices require a certain driver.
The x86 configuration builds drivers. The armv7 one doesn't (there are no useful drivers for this purpose).
Then IMO the dependency on the Linux kernel should be optional.
Quoted 3 lines
A user may serve its own configuration of DPDK where a kernel driver is selected and thus, the user would expect it to be built and installed.
Right. But if the default configuration doesn't require the kernel to be built, we probably shouldn't require it as well.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH v5 1/1 dpdk: new package
Hello,
Quoted 3 lines · Jan Viktorin
Well, your config is for ARMv7 so no kmods are built because all current drivers require PCI which is hardly to see on this platform (I know just about Armada).
Indeed mvebu_v7 is for Marvell Armada. Is DPDK only for PCI NICs? Can't it be used for the internal NICs of certain ARM SoCs ?
Quoted 2 lines
Ok. I don't know what would be the use case for dropping dependency on the kernel. Building just the rootfs without the kernel?
For example, yes. Another benefit of not having the mandatory kernel dependency is that the autobuilders would be able to test the DPDK package.
Quoted 2 lines
That means to check whether the kernel is enabled. And if it is then to enable building of the DPDK kernel modules. Right?
Correct.
Quoted 7 lines
This can be done but I am afraid I have to disable certain modules by name from the current configuration. This is not very generic (consider adding a new out-of-tree kernel module or removing an obsolete one from the DPDK, custom DPDK tree with third party modules) but there are only few of them so it might be a working solution. I will check if there is a more generic way but I don't think so.
I'm not sure what you mean here. If the default configuration on a given architecture builds kernel modules, then on this architecture, DPDK should depend on the kernel to be built. If the default configuration on another architecture does not build kernel modules, then there is no need to depend on the kernel.
That being said, if only ARM does not build any kernel module, maybe we can simply do as you do right now, and depend on the kernel unconditionally, to keep things simple.
Thanks!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH v5 1/1 dpdk: new package
Quoted 10 lines · On Sun, 17 Apr 2016 23:06:07 +0200 Thomas Petazzoni…
Hello,
Quoted 3 lines · Jan Viktorin
Well, your config is for ARMv7 so no kmods are built because all current drivers require PCI which is hardly to see on this platform (I know just about Armada).
Indeed
mvebu_v7is for Marvell Armada. Is DPDK only for PCI NICs? Can't it be used for the internal NICs of certain ARM SoCs ?
Yes. DPDK up to 16.04 supports only PCI devices. We are going to change this for 16.07 (the next release).
Quoted 7 lines
Quoted 3 lines
Ok. I don't know what would be the use case for dropping dependency on the kernel. Building just the rootfs without the kernel?
For example, yes. Another benefit of not having the mandatory kernel dependency is that the autobuilders would be able to test the DPDK package.
I have no clue about this. Does kernel dependency prevent some auto-testing?
Quoted 5 lines
Quoted 3 lines
That means to check whether the kernel is enabled. And if it is then to enable building of the DPDK kernel modules. Right?
Correct.
I would implement this in Buildroot by a list of configuration keys naming certain drivers. If the kernel is disabled, I'd disable all of them during configure phase. Otherwise, I'd leave them untouched (to have the current configuration as is). So, I'd put in dpdk.mk something like:
ifeq ($(BR2_LINUX_KERNEL),y)DPDK_DEPENDENCIES += linux
elseDPDK_KMODS = EAL_IGB_UIO KNI_KMOD LIBRTE_XEN_DOM0
define DPDK_DISABLE_KMODS
$(foreach m,$(DPDK_KMODS),\ $(call KCONFIG_DISABLE_OPT,CONFIG_RTE_$(m),$(@D)/build/.config))
endef
DPDK_POST_CONFIGURE_HOOKS += DPDK_DISABLE_KMODS
endif
Probably, I can improve it by testing whether a module is present in the DPDK config and then setting the dependency on linux.
Anyway, it seems to be quite complex...
Quoted 15 lines
Quoted 8 lines
This can be done but I am afraid I have to disable certain modules by name from the current configuration. This is not very generic (consider adding a new out-of-tree kernel module or removing an obsolete one from the DPDK, custom DPDK tree with third party modules) but there are only few of them so it might be a working solution. I will check if there is a more generic way but I don't think so.
I'm not sure what you mean here. If the default configuration on a given architecture builds kernel modules, then on this architecture, DPDK should depend on the kernel to be built. If the default configuration on another architecture does not build kernel modules, then there is no need to depend on the kernel.
Quoted 3 lines
That being said, if only ARM does not build any kernel module, maybe we can simply do as you do right now, and depend on the kernel unconditionally, to keep things simple.
Yes, this would work for the existing defconfigs. What about a custom one? E.g. I want some DPDK kernel modules for the Armada with a PCI-E NIC. So, I need a custom DPDK configuration at the moment. Fortunately, this is a rare case.
There is also a Xen module in DPDK that is not built by default so you have to create a custom configuration (or alter an existing one) to enable it.
I understand that you'd like to keep it as simple as possible. I'd like to keep it simple too but also providing enough flexibility for easy customizations. That's why I don't consider the ARMv7 configuration to be "without kernel modules" as it is possible to enable some if needed.
Regards
Jan
Quoted 4 lines
Thanks!
Thomas
Signature · 4 lines
Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic
PATCH v5 1/1 dpdk: new package
Quoted 7 lines · Jan Viktorin
Quoted 4 lines · On Sun, 17 Apr 2016 23:06:07 +0200 Thomas Petazzoni…
Hello,
On Sun, 17 Apr 2016 22:56:07 +0200, Jan Viktorin wrote:
[snip]
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines
Ok. I don't know what would be the use case for dropping dependency on the kernel. Building just the rootfs without the kernel?
For example, yes. Another benefit of not having the mandatory kernel dependency is that the autobuilders would be able to test the DPDK package.
I have no clue about this. Does kernel dependency prevent some auto-testing?
The base configs used in the autobuilders don't include a kernel (or
bootloader or rootfs). Therefore, any package depending on the kernel is never built.
We _could_ actually add a couple of base configs that do include a kernel. But
someone has to do it :-)
Quoted 13 lines
Quoted 6 lines
Quoted 4 lines
That means to check whether the kernel is enabled. And if it is then to enable building of the DPDK kernel modules. Right?
Correct.
I would implement this in Buildroot by a list of configuration keys naming certain drivers. If the kernel is disabled, I'd disable all of them during configure phase. Otherwise, I'd leave them untouched (to have the current configuration as is). So, I'd put in dpdk.mk something like:
Quoted 7 lines
ifeq ($(BR2_LINUX_KERNEL),y)
DPDK_DEPENDENCIES+= linux
elseDPDK_KMODS=EAL_IGB_UIOKNI_KMODLIBRTE_XEN_DOM0define
DPDK_DISABLE_KMODS
$(foreach m,$(DPDK_KMODS),\
Small nit: indent with tab here.
Quoted 4 lines
$(call KCONFIG_DISABLE_OPT,CONFIG_RTE_$(m),$(@D)/build/.config))endef
DPDK_POST_CONFIGURE_HOOKS+=DPDK_DISABLE_KMODS
Is dpdk using Kconfig? In that case, please use the kconfig-package infra. It
gives you simple primitives for disabling and enabling options. Consult the manual.
Quoted 4 lines
endif
Probably, I can improve it by testing whether a module is present in the DPDK config and then setting the dependency on linux.
That's not possible: DEPENDENCIES must be declared when the makefiles are
parsed, but the tarball containing .config is only extracted afterwards.
Regards,
Arnout
Quoted 35 lines
Anyway, it seems to be quite complex...
Quoted 15 lines
Quoted 8 lines
This can be done but I am afraid I have to disable certain modules by name from the current configuration. This is not very generic (consider adding a new out-of-tree kernel module or removing an obsolete one from the DPDK, custom DPDK tree with third party modules) but there are only few of them so it might be a working solution. I will check if there is a more generic way but I don't think so.
I'm not sure what you mean here. If the default configuration on a given architecture builds kernel modules, then on this architecture, DPDK should depend on the kernel to be built. If the default configuration on another architecture does not build kernel modules, then there is no need to depend on the kernel.
Quoted 3 lines
That being said, if only ARM does not build any kernel module, maybe we can simply do as you do right now, and depend on the kernel unconditionally, to keep things simple.
Yes, this would work for the existing defconfigs. What about a custom one? E.g. I want some DPDK kernel modules for the Armada with a PCI-E NIC. So, I need a custom DPDK configuration at the moment. Fortunately, this is a rare case.
There is also a Xen module in DPDK that is not built by default so you have to create a custom configuration (or alter an existing one) to enable it.
I understand that you'd like to keep it as simple as possible. I'd like to keep it simple too but also providing enough flexibility for easy customizations. That's why I don't consider the ARMv7 configuration to be "without kernel modules" as it is possible to enable some if needed.
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH v5 1/1 dpdk: new package
Hello Arnout,
thanks for your comments...
Quoted 19 lines · On Tue, 19 Apr 2016 00:50:27 +0200 Arnout Vandecappelle <[email protected]> wrote:
Quoted 7 lines · Jan Viktorin
Quoted 4 lines · On Sun, 17 Apr 2016 23:06:07 +0200 Thomas Petazzoni…
Hello,
On Sun, 17 Apr 2016 22:56:07 +0200, Jan Viktorin wrote:
[snip]
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines
Ok. I don't know what would be the use case for dropping dependency on the kernel. Building just the rootfs without the kernel?
For example, yes. Another benefit of not having the mandatory kernel dependency is that the autobuilders would be able to test the DPDK package.
I have no clue about this. Does kernel dependency prevent some auto-testing?
Quoted 6 lines
The base configs used in the autobuilders don't include a kernel (or
bootloader or rootfs). Therefore, any package depending on the kernel is never built.We _could_ actually add a couple of base configs that do include a kernel. But
someone has to do it :-)
I have no idea how to access the autobuilder nor what kind of complexity is connected with this...
Quoted 19 lines
Quoted 19 lines
Quoted 7 lines
Quoted 5 lines
That means to check whether the kernel is enabled. And if it is then to enable building of the DPDK kernel modules. Right?
Correct.
I would implement this in Buildroot by a list of configuration keys naming certain drivers. If the kernel is disabled, I'd disable all of them during configure phase. Otherwise, I'd leave them untouched (to have the current configuration as is). So, I'd put in dpdk.mk something like:
ifeq ($(BR2_LINUX_KERNEL),y)
DPDK_DEPENDENCIES+= linux
elseDPDK_KMODS=EAL_IGB_UIOKNI_KMODLIBRTE_XEN_DOM0
Quoted 4 lines
Quoted 2 lines
define
DPDK_DISABLE_KMODS
$(foreach m,$(DPDK_KMODS),\Small nit: indent with tab here.
OK, it was just an ad hoc example. I'd rather know whether I can implement it this way.
Quoted 8 lines
Quoted 5 lines
$(call KCONFIG_DISABLE_OPT,CONFIG_RTE_$(m),$(@D)/build/.config))endef
DPDK_POST_CONFIGURE_HOOKS+=DPDK_DISABLE_KMODSIs dpdk using
Kconfig? In that case, please use the kconfig-package infra. It
gives you simple primitives for disabling and enabling options. Consult the manual.
Unfortunately, there is no kconfig. It just looks this way. The buildsystem is custom.
Quoted 8 lines
Quoted 5 lines
endif
Probably, I can improve it by testing whether a module is present in the DPDK config and then setting the dependency on linux.
That's not possible: DEPENDENCIES must be declared when the makefiles are
parsed, but the tarball containing .config is only extracted afterwards.
OK, it was just an idea.
Regards
Jan
Quoted 43 lines
Regards,
ArnoutQuoted 35 lines
Anyway, it seems to be quite complex...
Quoted 15 lines
Quoted 8 lines
This can be done but I am afraid I have to disable certain modules by name from the current configuration. This is not very generic (consider adding a new out-of-tree kernel module or removing an obsolete one from the DPDK, custom DPDK tree with third party modules) but there are only few of them so it might be a working solution. I will check if there is a more generic way but I don't think so.
I'm not sure what you mean here. If the default configuration on a given architecture builds kernel modules, then on this architecture, DPDK should depend on the kernel to be built. If the default configuration on another architecture does not build kernel modules, then there is no need to depend on the kernel.
Quoted 3 lines
That being said, if only ARM does not build any kernel module, maybe we can simply do as you do right now, and depend on the kernel unconditionally, to keep things simple.
Yes, this would work for the existing defconfigs. What about a custom one? E.g. I want some DPDK kernel modules for the Armada with a PCI-E NIC. So, I need a custom DPDK configuration at the moment. Fortunately, this is a rare case.
There is also a Xen module in DPDK that is not built by default so you have to create a custom configuration (or alter an existing one) to enable it.
I understand that you'd like to keep it as simple as possible. I'd like to keep it simple too but also providing enough flexibility for easy customizations. That's why I don't consider the ARMv7 configuration to be "without kernel modules" as it is possible to enable some if needed.
Signature · 4 lines
Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic
PATCH v5 1/1 dpdk: new package
Quoted 30 lines · Jan Viktorin
Hello Arnout,
thanks for your comments...
Quoted 23 lines · On Tue, 19 Apr 2016 00:50:27 +0200 Arnout Vandecappelle <[email protected]> wrote:
Quoted 7 lines · Jan Viktorin
Quoted 4 lines · On Sun, 17 Apr 2016 23:06:07 +0200 Thomas Petazzoni…
Hello,
On Sun, 17 Apr 2016 22:56:07 +0200, Jan Viktorin wrote:
[snip]
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines
Ok. I don't know what would be the use case for dropping dependency on the kernel. Building just the rootfs without the kernel?
For example, yes. Another benefit of not having the mandatory kernel dependency is that the autobuilders would be able to test the DPDK package.
I have no clue about this. Does kernel dependency prevent some auto-testing?
The base configs used in the autobuilders don't include a kernel (or
bootloader or rootfs). Therefore, any package depending on the kernel is never built.
Quoted 5 lines
Quoted 2 lines
We _could_ actually add a couple of base configs that do include a kernel. But
someone has to do it :-)I have no idea how to access the autobuilder nor what kind of complexity is connected with this...
git://git.buildroot.net/buildroot-test/
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
I would implement this in Buildroot by a list of configuration keys naming certain drivers. If the kernel is disabled, I'd disable all of them during configure phase. Otherwise, I'd leave them untouched (to have the current configuration as is). So, I'd put in dpdk.mk something like:
ifeq ($(BR2_LINUX_KERNEL),y)
DPDK_DEPENDENCIES+= linux
elseDPDK_KMODS=EAL_IGB_UIOKNI_KMODLIBRTE_XEN_DOM0
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
define
DPDK_DISABLE_KMODS
$(foreach m,$(DPDK_KMODS),\Small nit: indent with tab here.
OK, it was just an ad hoc example. I'd rather know whether I can implement it this way.
Yes it can.
If you don't disable these options, what will the dpdk build system do? Error
out? Or try to use the build system's kernel? Ideally there would be a way to globally tell it not to build modules. Manually maintaining a list of config options to disable is a bit cumbersome.
Quoted 11 lines
Quoted 9 lines
Quoted 6 lines
$(call KCONFIG_DISABLE_OPT,CONFIG_RTE_$(m),$(@D)/build/.config))endef
DPDK_POST_CONFIGURE_HOOKS+=DPDK_DISABLE_KMODSIs dpdk using
Kconfig? In that case, please use the kconfig-package infra. It
gives you simple primitives for disabling and enabling options. Consult the manual.Unfortunately, there is no kconfig. It just looks this way. The buildsystem is custom.
So you have to manually create a config file with lines like
# CONFIG_FOO is not set
? How uncomfortable...
Quoted 11 lines
Quoted 9 lines
Quoted 6 lines
endif
Probably, I can improve it by testing whether a module is present in the DPDK config and then setting the dependency on linux.
That's not possible: DEPENDENCIES must be declared when the makefiles are
parsed, but the tarball containing .config is only extracted afterwards.OK, it was just an idea.
We can also still revert to depending on linux unconditionally like you have
now. How likely is it that dpdk will be used in practice with no kernel modules? Or is this going to be more likely in the future, with heavier use of UIO and device tree?
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH v5 1/1 dpdk: new package
Hello,
Quoted 4 lines · Arnout Vandecappelle
We can also still revert to depending on linux unconditionally like you have
now. How likely is it that dpdk will be used in practice with no kernel modules? Or is this going to be more likely in the future, with heavier use of UIO and device tree?
My proposal would indeed to revert back to depend on Linux unconditionally, and see what happens later, like if we have users who use DPDK and complain that it depends on the Linux kernel package.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH v5 1/1 dpdk: new package
In reply to Arnout VandecappelleQuoted 54 lines · On Tue, 19 Apr 2016 21:30:10 +0200 Arnout Vandecappelle <[email protected]> wrote:
Quoted 30 lines · Jan Viktorin
Hello Arnout,
thanks for your comments...
Quoted 23 lines · On Tue, 19 Apr 2016 00:50:27 +0200 Arnout Vandecappelle <[email protected]> wrote:
Quoted 7 lines · Jan Viktorin
Quoted 4 lines · On Sun, 17 Apr 2016 23:06:07 +0200 Thomas Petazzoni…
Hello,
On Sun, 17 Apr 2016 22:56:07 +0200, Jan Viktorin wrote:
[snip]
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines
Ok. I don't know what would be the use case for dropping dependency on the kernel. Building just the rootfs without the kernel?
For example, yes. Another benefit of not having the mandatory kernel dependency is that the autobuilders would be able to test the DPDK package.
I have no clue about this. Does kernel dependency prevent some auto-testing?
The base configs used in the autobuilders don't include a kernel (or
bootloader or rootfs). Therefore, any package depending on the kernel is never built.Quoted 5 lines
Quoted 2 lines
We _could_ actually add a couple of base configs that do include a kernel. But
someone has to do it :-)I have no idea how to access the autobuilder nor what kind of complexity is connected with this...
git://git.buildroot.net/buildroot-test/Quoted 14 lines
Quoted 14 lines
Quoted 13 lines
I would implement this in Buildroot by a list of configuration keys naming certain drivers. If the kernel is disabled, I'd disable all of them during configure phase. Otherwise, I'd leave them untouched (to have the current configuration as is). So, I'd put in dpdk.mk something like:
ifeq ($(BR2_LINUX_KERNEL),y)
DPDK_DEPENDENCIES+= linux
elseDPDK_KMODS=EAL_IGB_UIOKNI_KMODLIBRTE_XEN_DOM0define
DPDK_DISABLE_KMODS
$(foreach m,$(DPDK_KMODS),\
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
Small nit: indent with tab here.
OK, it was just an ad hoc example. I'd rather know whether I can implement it this way.
Yes it can.
If you don't disable these options, what will the dpdk build system do? Error
out? Or try to use the build system's kernel? Ideally there would be a way to
My experience is that if I don't pass the location of the kernel sources it finds out some local one installed on the host system or it errors out. Only the ARMv7 config builds as it disables all the modules (unsupported).
It was not primarily developed with a cross-compilation support. The target system is x86-something... The ARM support is something very new.
Quoted 2 lines
globally tell it not to build modules. Manually maintaining a list of config options to disable is a bit cumbersome.
No, the modules are built based on the configuration, so an entry like CONFIG_* something.
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
$(call KCONFIG_DISABLE_OPT,CONFIG_RTE_$(m),$(@D)/build/.config))endef
DPDK_POST_CONFIGURE_HOOKS+=DPDK_DISABLE_KMODS
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
Is dpdk using
Kconfig? In that case, please use the kconfig-package infra. It
gives you simple primitives for disabling and enabling options. Consult the manual.Unfortunately, there is no kconfig. It just looks this way. The buildsystem is custom.
So you have to manually create a config file with lines like
#CONFIG_FOOis not set
Those lines are not used. There is no dependency check...
Quoted 1 line
? How uncomfortable...
Not really. But yes ;). The new defconfigs include some core ones (e.g. common_linuxapp) and just disable what they don't need or vice-versa...
Quoted 11 lines
Quoted 11 lines
Quoted 10 lines
Quoted 7 lines
endif
Probably, I can improve it by testing whether a module is present in the DPDK config and then setting the dependency on linux.
That's not possible: DEPENDENCIES must be declared when the makefiles are
parsed, but the tarball containing .config is only extracted afterwards.
Quoted 6 lines
Quoted 1 line
OK, it was just an idea.
We can also still revert to depending on linux unconditionally like you have
now. How likely is it that dpdk will be used in practice with no kernel modules? Or is this going to be more likely in the future, with heavier use of UIO and device tree?
I think that the DPDK community is going to use the mainline drivers as much as possible (vfio). As far as I know, the UIO is considered broken as it exposes too much into the userspace. Moreover, they want to be supported by the major distros so anything very custom is not very good. There are however two modules that are probably not to be upstreamed: kni (connection between DPDK and the kernel network stack) and xen (globally disabled by default). I've never used them myself but others probably do...
Regards
Jan
Quoted 5 lines
Regards,
Arnout
Signature · 4 lines
Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic