[dpdk-dev] [PATCH v7 00/11] Add installation rules for dpdk files.
DPDK package lacks of a mechanism to install libraries, headers applications, kernel modules and sdk files to a file system tree. This patch set allows to install files based on the next proposal: http://www.freedesktop.org/software/systemd/man/file-hierarchy.html v7: When "make install" is invoked if "T" variable is defined, the installation process will have the current behaviour, else "install-fhs" rule will be called. Using rules support is possible to do the next steps: make config T= make make Modify the makefile target to specify the files that will be installed using a rule: * make install-bin (install app files)(dafault path bindir=$(exec_prefix)/bin). * make install-headers (install headers)(dafault path includedir=$(prefix)/include/dpdk). * make install-lib (install libraries)(dafault path libdir=$(exec_prefix)/lib). * make install-doc (install documentation)(dafault path docdir=$(datarootdir)/doc/dpdk). * make install-mod (install modules)(dafault path if RTE_EXEC_ENV=linuxapp then kerneldir=/lib/modules/$(uname -r)/extra/drivers/dpdk else kerneldir=/boot/modules). * make install-sdk (install headers, makefiles, scripts,examples and config files) (default path sdkdir=$(datadir)/share/dpdk). * make install-fhs (install libraries, modules, app files, nic bind files (tools) and documentation). * make install (if T is defined current behaviour, else it will call install-fhs rule). where prefix=/usr/local, exec_prefix=$(prefix), datarootdir=$(prefix)/share, and datadir=$(datarootdir)/dpdk by default. Also you can use the DESTDIR var. All directory variables mentioned above can be overridden (bindir, libdir, includedir, docidr, kerneldir, prefix, exec_prefix and data). Furthermore this information is added to documentation. v6: When "make install" is invoked if "T" variable is defined, the installation process will have the current behaviour, else "install-fhs" rule will be called. Using rules support is possible to do the next steps: make config T= make make Modify the makefile target to specify the files that will be installed using a rule: * make install-bin (install app files)(dafault path BIN_DIR=$(RTE_PREFIX)/bin). * make install-headers (install headers)(dafault path INCLUDE_DIR=$(RTE_PREFIX)/include/dpdk). * make install-lib (install libraries)(dafault path LIB_DIR=$(RTE_PREFIX)/lib). * make install-doc (install documentation)(dafault path DOC_DIR=$(RTE_PREFIX)/share/doc/dpdk). * make install-mod (install modules)(dafault path if RTE_EXEC_ENV=linuxapp then KMOD_DIR=/lib/modules/$(uname -r)/extra/drivers/dpdk else KMOD_DIR=/boot/modules). * make install-sdk (install headers, makefiles, scripts,examples, tools and config files) (default path DATA_DIR=$(RTE_PREFIX)/share/dpdk). * make install-fhs (install libraries, modules, app files, nic bind files and documentation). * make install (if T is defined current behaviour, else it will call install-fhs rule ) where RTE_PREFIX=/usr/local by default. Also you can use the DESTDIR var. All directory variables mentioned above can be overridden (BIN_DIR, LIB_DIR, INCLUDE_DIR, DOC_DIR, KMOD_DIR, RTE_PREFIX and DATA_DIR). Furthermore this information is added to documentation. v5: When "make install" is invoked if "T" variable is defined, the installation process will have the current behaviour, else "install-fhs" rule will be called. Using rules support is possible to do the next steps: make config T= make make Modify the makefile target to specify the files that will be installed using a rule: * make install-bin (install app files)(dafault path BIN_DIR=$(RTE_PREFIX)/bin). * make install-headers (install headers)(dafault path INCLUDE_DIR=$(RTE_PREFIX)/include/dpdk). * make install-lib (install libraries)(dafault path LIB_DIR=$(RTE_PREFIX)/lib). * make install-doc (install documentation)(dafault path DOC_DIR=$(RTE_PREFIX)/share/doc/dpdk). * make install-mod (install modules)(dafault path if RTE_EXEC_ENV=linuxapp then KMOD_DIR=/lib/modules/$(uname -r)/extra/drivers/dpdk else KMOD_DIR=/boot/modules). * make install-sdk (install headers, makefiles, scripts,examples, tools and config files) (default path DATA_DIR=$(RTE_PREFIX)/share/dpdk). * make install-fhs (install libraries, modules, app files, nic bind files and documentation). * make install (if T is defined current behaviour, else it will call install-fhs rule ) where RTE_PREFIX=/usr/local by default. Also you can use the DESTDIR var. All directory variables mentioned above can be overridden (BIN_DIR, LIB_DIR, INCLUDE_DIR, DOC_DIR, KMOD_DIR, RTE_PREFIX and DATA_DIR). Furthermore this information is added to documentation (build-sdk-quick.txt file) v4: Add instalation rules for dpdk files. DPDK package lacks of a mechanism to install libraries, headers applications, kernel modules and sdk files
[dpdk-dev] [PATCH v7 02/11] mk: Add rule for installing app files
Add hierarchy-file support to the DPDK app files,
nic bind file and cpu layout file
when invoking "make install-bin" app files will
be installed in: $(DESTDIR)/$(bindir)
where bindir=$(exec_prefix)/usr/local/bin
prefix=/usr/local
and exec_prefix=$(prefix) by default,
you can override prefix, exec_prefix and bindir vars.
This hierarchy is based on:
http://www.freedesktop.org/software/systemd/man/file-hierarchy.html
and variables are based on:
https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
https://www.gnu.org/prep/standards/html_node/DESTDIR.html
Signed-off-by: Mario Carrillo
---
mk/rte.sdkinstall.mk | 19 +++
mk/rte.sdkroot.mk| 4 ++--
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk
index a4a01cf..93de06b 100644
--- a/mk/rte.sdkinstall.mk
+++ b/mk/rte.sdkinstall.mk
@@ -43,8 +43,13 @@ ifndef T
T=*
ifneq (,$(wildcard $(RTE_OUTPUT)/.config))
prefix ?= /usr/local
+exec_prefix ?= $(prefix)
includedir ?= $(prefix)/include/dpdk
+bindir ?= $(exec_prefix)/bin
HSLINKS := $(shell find $(RTE_OUTPUT)/include/ -name *.h)
+BINARY_FILES := $(patsubst %.map,,$(wildcard $(RTE_OUTPUT)/app/*))
+NIC_FILES := $(wildcard $(RTE_SDK)/tools/*.py)
+BINARY_FILES += $(NIC_FILES)
endif
endif
@@ -94,6 +99,20 @@ install-headers:
done \
fi
#
+# install app files in /usr/local/bin by default
+# "prefix" and "bindir" can be overridden.
+#
+.PHONY: install-bin
+install-bin:
+ @echo == Installing app files;
+ @if [ ! -z "${BINARY_FILES}" ]; then \
+ [ -d $(DESTDIR)/$(bindir) ] || mkdir -p $(DESTDIR)/$(bindir); \
+ for BIN_FILE in ${BINARY_FILES}; do \
+ cp -rf $$BIN_FILE ${DESTDIR}/${bindir}; \
+ echo installing: $$BIN_FILE; \
+ done \
+ fi
+#
# uninstall: remove all built sdk
#
UNINSTALL_TARGETS := $(addsuffix _uninstall,\
diff --git a/mk/rte.sdkroot.mk b/mk/rte.sdkroot.mk
index 8477a2b..24eaa60 100644
--- a/mk/rte.sdkroot.mk
+++ b/mk/rte.sdkroot.mk
@@ -97,8 +97,8 @@ test fast_test ring_test mempool_test perf_test coverage:
testall:
$(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdktestall.mk $@
-.PHONY: install install-headers uninstall
-install install-headers uninstall:
+.PHONY: install install-headers install-bin uninstall
+install install-headers install-bin uninstall:
$(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkinstall.mk $@
.PHONY: doc help
--
2.6.3
[dpdk-dev] [PATCH v7 03/11] mk: Add rule for installing libraries
Add hierarchy-file support to the DPDK libraries,
when invoking "make install-lib" libraries will
be installed in: $(DESTDIR)/$(libdir)
where libdir=$(exec_prefix)/usr/lib
prefix=/usr/local
and exec_prefix=$(prefix) by default,
you can override prefix, exec_prefix and libdir vars.
This hierarchy is based on:
http://www.freedesktop.org/software/systemd/man/file-hierarchy.html
and variables are based on:
https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
https://www.gnu.org/prep/standards/html_node/DESTDIR.html
Signed-off-by: Mario Carrillo
---
mk/rte.sdkinstall.mk | 16
mk/rte.sdkroot.mk| 4 ++--
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk
index 93de06b..ff99afe 100644
--- a/mk/rte.sdkinstall.mk
+++ b/mk/rte.sdkinstall.mk
@@ -46,9 +46,11 @@ prefix ?= /usr/local
exec_prefix ?= $(prefix)
includedir ?= $(prefix)/include/dpdk
bindir ?= $(exec_prefix)/bin
+libdir ?= $(exec_prefix)/lib
HSLINKS := $(shell find $(RTE_OUTPUT)/include/ -name *.h)
BINARY_FILES := $(patsubst %.map,,$(wildcard $(RTE_OUTPUT)/app/*))
NIC_FILES := $(wildcard $(RTE_SDK)/tools/*.py)
+LIBS := $(wildcard $(RTE_OUTPUT)/lib/*)
BINARY_FILES += $(NIC_FILES)
endif
endif
@@ -113,6 +115,20 @@ install-bin:
done \
fi
#
+# install libs in /usr/local/lib by default
+# "prefix" and "libdir" can be overridden.
+#
+.PHONY: install-lib
+install-lib:
+ @echo == Installing libraries
+ @if [ ! -z "${LIBS}" ]; then \
+ [ -d $(DESTDIR)/$(libdir) ] || mkdir -p $(DESTDIR)/$(libdir); \
+ for LIB in ${LIBS}; do \
+ cp -rf $$LIB ${DESTDIR}/${libdir}; \
+ echo installing: $$LIB; \
+ done \
+ fi
+#
# uninstall: remove all built sdk
#
UNINSTALL_TARGETS := $(addsuffix _uninstall,\
diff --git a/mk/rte.sdkroot.mk b/mk/rte.sdkroot.mk
index 24eaa60..7a72c9b 100644
--- a/mk/rte.sdkroot.mk
+++ b/mk/rte.sdkroot.mk
@@ -97,8 +97,8 @@ test fast_test ring_test mempool_test perf_test coverage:
testall:
$(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdktestall.mk $@
-.PHONY: install install-headers install-bin uninstall
-install install-headers install-bin uninstall:
+.PHONY: install install-headers install-bin install-lib uninstall
+install install-headers install-bin install-lib uninstall:
$(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkinstall.mk $@
.PHONY: doc help
--
2.6.3
[dpdk-dev] [PATCH v7 04/11] mk: Add rule for installing modules
Add hierarchy-file support to the DPDK modules,
when invoking "make install-mod" modules will be
installed in: $(DESTDIR)/$(kerneldir)
if RTE_EXEC_ENV=linuxapp then
kerneldir=/lib/modules/$(uname -r)/extra/drivers/dpdk
else kerneldir=/boot/modules
by default, you can override "kerneldir" var.
This hierarchy is based on:
http://www.freedesktop.org/software/systemd/man/file-hierarchy.html
Signed-off-by: Mario Carrillo
---
mk/rte.sdkinstall.mk | 24
mk/rte.sdkroot.mk| 4 ++--
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk
index ff99afe..1502399 100644
--- a/mk/rte.sdkinstall.mk
+++ b/mk/rte.sdkinstall.mk
@@ -51,7 +51,15 @@ HSLINKS := $(shell find $(RTE_OUTPUT)/include/ -name *.h)
BINARY_FILES := $(patsubst %.map,,$(wildcard $(RTE_OUTPUT)/app/*))
NIC_FILES := $(wildcard $(RTE_SDK)/tools/*.py)
LIBS := $(wildcard $(RTE_OUTPUT)/lib/*)
+MODULES := $(wildcard $(RTE_OUTPUT)/kmod/*)
BINARY_FILES += $(NIC_FILES)
+include $(RTE_OUTPUT)/.config
+RTE_EXEC_ENV := $(CONFIG_RTE_EXEC_ENV:"%"=%)
+ifeq ($(RTE_EXEC_ENV),linuxapp)
+kerneldir ?= /lib/modules/$(shell uname -r)/extra/drivers/dpdk
+else
+kerneldir ?= /boot/modules
+endif
endif
endif
@@ -129,6 +137,22 @@ install-lib:
done \
fi
#
+# if RTE_EXEC_ENV=linuxapp modules install in:
+# /lib/modules/$(uname -r)/extra/drivers/dpdk
+# else /boot/modules/ by default
+# "kerneldir" var can be overridden.
+#
+.PHONY: install-mod
+install-mod:
+ @echo == Installing modules
+ @if [ ! -z "${MODULES}" ]; then \
+ [ -d $(DESTDIR)/$(kerneldir) ] || mkdir -p $(DESTDIR)/$(kerneldir); \
+ for MOD in ${MODULES}; do \
+ cp -rf $$MOD ${DESTDIR}/${kerneldir}; \
+ echo installing: $$MOD; \
+ done \
+ fi
+#
# uninstall: remove all built sdk
#
UNINSTALL_TARGETS := $(addsuffix _uninstall,\
diff --git a/mk/rte.sdkroot.mk b/mk/rte.sdkroot.mk
index 7a72c9b..e652218 100644
--- a/mk/rte.sdkroot.mk
+++ b/mk/rte.sdkroot.mk
@@ -97,8 +97,8 @@ test fast_test ring_test mempool_test perf_test coverage:
testall:
$(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdktestall.mk $@
-.PHONY: install install-headers install-bin install-lib uninstall
-install install-headers install-bin install-lib uninstall:
+.PHONY: install install-headers install-bin install-lib install-mod uninstall
+install install-headers install-bin install-lib install-mod uninstall:
$(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkinstall.mk $@
.PHONY: doc help
--
2.6.3
[dpdk-dev] [PATCH v7 05/11] mk: Add rule for installing documentation
Add hierarchy-file support to the DPDK documentation,
when invoking "make install-doc" documentation files will
be installed in: $(DESTDIR)/$(docdir) where
docdir=$(datarootdir)/doc/dpdk
datarootdir=$(prefix)/share
prefix=/usr/local by default, you can override "prefix",
"datarootdir" and "docdir" vars.
This hierarchy is based on:
http://www.freedesktop.org/software/systemd/man/file-hierarchy.html
and variables are based on:
https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
https://www.gnu.org/prep/standards/html_node/DESTDIR.html
Signed-off-by: Mario Carrillo
---
mk/rte.sdkinstall.mk | 17 +
mk/rte.sdkroot.mk| 5 +++--
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk
index 1502399..c062489 100644
--- a/mk/rte.sdkinstall.mk
+++ b/mk/rte.sdkinstall.mk
@@ -47,11 +47,14 @@ exec_prefix ?= $(prefix)
includedir ?= $(prefix)/include/dpdk
bindir ?= $(exec_prefix)/bin
libdir ?= $(exec_prefix)/lib
+datarootdir ?= $(prefix)/share
+docdir ?= $(datarootdir)/doc/dpdk
HSLINKS := $(shell find $(RTE_OUTPUT)/include/ -name *.h)
BINARY_FILES := $(patsubst %.map,,$(wildcard $(RTE_OUTPUT)/app/*))
NIC_FILES := $(wildcard $(RTE_SDK)/tools/*.py)
LIBS := $(wildcard $(RTE_OUTPUT)/lib/*)
MODULES := $(wildcard $(RTE_OUTPUT)/kmod/*)
+DOCS := $(wildcard $(RTE_SDK)/doc/*)
BINARY_FILES += $(NIC_FILES)
include $(RTE_OUTPUT)/.config
RTE_EXEC_ENV := $(CONFIG_RTE_EXEC_ENV:"%"=%)
@@ -153,6 +156,20 @@ install-mod:
done \
fi
#
+# install documentation in /usr/local/share/doc/dpdk
+# by default, "docdir", "prefix" and "datarootdir" vars can be overriden.
+#
+.PHONY: install-doc
+install-doc:
+ @echo == Installing documentation
+ @if [ ! -z "${DOCS}" ]; then \
+ [ -d $(DESTDIR)/$(docdir) ] || mkdir -p $(DESTDIR)/$(docdir); \
+ for DOC in ${DOCS}; do \
+ cp -rf $$DOC ${DESTDIR}/${docdir}; \
+ echo installing: $$DOC; \
+ done \
+ fi
+#
# uninstall: remove all built sdk
#
UNINSTALL_TARGETS := $(addsuffix _uninstall,\
diff --git a/mk/rte.sdkroot.mk b/mk/rte.sdkroot.mk
index e652218..f56341d 100644
--- a/mk/rte.sdkroot.mk
+++ b/mk/rte.sdkroot.mk
@@ -97,8 +97,9 @@ test fast_test ring_test mempool_test perf_test coverage:
testall:
$(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdktestall.mk $@
-.PHONY: install install-headers install-bin install-lib install-mod uninstall
-install install-headers install-bin install-lib install-mod uninstall:
+.PHONY: install install-headers install-bin install-lib install-mod \
+install-doc uninstall
+install install-headers install-bin install-lib install-mod install-doc
uninstall:
$(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkinstall.mk $@
.PHONY: doc help
--
2.6.3
[dpdk-dev] [PATCH v7 06/11] mk: Add rule for installing sdk files
Add hierarchy-file support to the DPDK makefiles, scripts, examples, tools, config files and headers, when invoking "make install-sdk" makefiles, scripts, examples and config files will be installed in: $(DESTDIR)/$(sdkdir) and headers will be installed in: $(DESTDIR)/$(includedir) where sdkdir=$(datadir) datadir=$(datarootdir)/dpdk datarootdir=$(prefix)/share includedir=$(prefix)/include/dpdk prefix=/usr/local by default, you can override "prefix", "sdkdir", "datadir", "datarootdir" and "includedir" vars. This hierarchy is based on: http://www.freedesktop.org/software/systemd/man/file-hierarchy.html and variables are based on: https://www.gnu.org/prep/standards/html_node/Directory-Variables.html https://www.gnu.org/prep/standards/html_node/DESTDIR.html Signed-off-by: Mario Carrillo --- mk/rte.sdkinstall.mk | 19 +++ mk/rte.sdkroot.mk| 5 +++-- 2 files changed, 22 insertions(+), 2 deletions(-) diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk index c062489..09950fa 100644 --- a/mk/rte.sdkinstall.mk +++ b/mk/rte.sdkinstall.mk @@ -49,6 +49,8 @@ bindir ?= $(exec_prefix)/bin libdir ?= $(exec_prefix)/lib datarootdir ?= $(prefix)/share docdir ?= $(datarootdir)/doc/dpdk +datadir ?= $(datarootdir)/dpdk +sdkdir ?= $(datadir) HSLINKS := $(shell find $(RTE_OUTPUT)/include/ -name *.h) BINARY_FILES := $(patsubst %.map,,$(wildcard $(RTE_OUTPUT)/app/*)) NIC_FILES := $(wildcard $(RTE_SDK)/tools/*.py) @@ -170,6 +172,23 @@ install-doc: done \ fi # +# install sdk files in /usr/local/share/dpdk by default +# where prefix and "sdkdir", "datadir" and "prefix" var can be overridden. +# +.PHONY: install-sdk +install-sdk: install-headers + @echo == Installing sdk files + @[ -d $(DESTDIR)/$(sdkdir) ] || mkdir -p $(DESTDIR)/$(sdkdir); \ + cp -rf $(RTE_SDK)/mk $(DESTDIR)/$(sdkdir); \ + echo installing: $(RTE_SDK)/mk; \ + cp -rf $(RTE_SDK)/scripts $(DESTDIR)/$(sdkdir); \ + echo installing: $(RTE_SDK)/scripts; \ + cp -rf $(RTE_SDK)/examples $(DESTDIR)/$(sdkdir); \ + echo installing: $(RTE_SDK)/examples; + @[ -d $(DESTDIR)/$(sdkdir)/config ] || mkdir -p $(DESTDIR)/$(sdkdir)/config; \ + cp -f $(RTE_SDK)/build/.config $(DESTDIR)/$(sdkdir)/config; \ + echo installing: $(RTE_OUTPUT)/.config +# # uninstall: remove all built sdk # UNINSTALL_TARGETS := $(addsuffix _uninstall,\ diff --git a/mk/rte.sdkroot.mk b/mk/rte.sdkroot.mk index f56341d..6fac88a 100644 --- a/mk/rte.sdkroot.mk +++ b/mk/rte.sdkroot.mk @@ -98,8 +98,9 @@ testall: $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdktestall.mk $@ .PHONY: install install-headers install-bin install-lib install-mod \ -install-doc uninstall -install install-headers install-bin install-lib install-mod install-doc uninstall: +install-doc install-sdk uninstall +install install-headers install-bin install-lib install-mod install-doc \ +install-sdk uninstall: $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkinstall.mk $@ .PHONY: doc help -- 2.6.3
[dpdk-dev] [PATCH v7 07/11] mk: Add rule for installing runtime files
Add hierarchy-file support to the DPDK libraries, modules, binary files, nic bind file, cpu layout file (tools) and documentation, when invoking "make install-fhs" (filesystem hierarchy standard) runtime files will be by default installed in: $(DESTDIR)/$(bindir) where bindir=$(exec_prefix)/bin (binary files) $(DESTDIR)/$(docdir) where docdir=$(datarootdir)/doc/dpdk (documentation) $(DESTDIR)/$(libdir) where libdir=$(exec_prefix)/lib (libraries) $(DESTDIR)/$(kerneldir) (modules) if RTE_EXEC_ENV=linuxapp then kerneldir=/lib/modules/$(uname -r)/extra/drivers/dpdk else kerneldir=/boot/modules exec_prefix=$(prefix) datarootdir=$(prefix)/share and prefix=/usr/local All directory variables mentioned above can be overridden. This hierarchy is based on: http://www.freedesktop.org/software/systemd/man/file-hierarchy.html and variables are based on: https://www.gnu.org/prep/standards/html_node/Directory-Variables.html https://www.gnu.org/prep/standards/html_node/DESTDIR.html Signed-off-by: Mario Carrillo --- mk/rte.sdkinstall.mk | 9 + mk/rte.sdkroot.mk| 4 ++-- 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk index 09950fa..d1ff160 100644 --- a/mk/rte.sdkinstall.mk +++ b/mk/rte.sdkinstall.mk @@ -189,6 +189,15 @@ install-sdk: install-headers cp -f $(RTE_SDK)/build/.config $(DESTDIR)/$(sdkdir)/config; \ echo installing: $(RTE_OUTPUT)/.config # +# install runtime files +# +.PHONY: install-fhs +install-fhs: install-lib install-bin install-doc install-mod + @echo == Installing runtime files + @[ -d $(DESTDIR)/$(datadir) ] || mkdir -p $(DESTDIR)/$(datadir); \ + cp -rf $(RTE_SDK)/tools $(DESTDIR)/$(datadir); \ + echo installing: $(RTE_SDK)/tools +# # uninstall: remove all built sdk # UNINSTALL_TARGETS := $(addsuffix _uninstall,\ diff --git a/mk/rte.sdkroot.mk b/mk/rte.sdkroot.mk index 6fac88a..dd5f399 100644 --- a/mk/rte.sdkroot.mk +++ b/mk/rte.sdkroot.mk @@ -98,9 +98,9 @@ testall: $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdktestall.mk $@ .PHONY: install install-headers install-bin install-lib install-mod \ -install-doc install-sdk uninstall +install-doc install-sdk install-fhs uninstall install install-headers install-bin install-lib install-mod install-doc \ -install-sdk uninstall: +install-sdk install-fhs uninstall: $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkinstall.mk $@ .PHONY: doc help -- 2.6.3
[dpdk-dev] [PATCH v7 08/11] app: Change name to test binary
This is order to test could be installed in a file herarchy and do not make a colision with test command from coreutils package. Signed-off-by: Mario Carrillo --- app/test/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/app/test/Makefile b/app/test/Makefile index ec33e1a..184f91b 100644 --- a/app/test/Makefile +++ b/app/test/Makefile @@ -36,7 +36,7 @@ ifeq ($(CONFIG_RTE_APP_TEST),y) # # library name # -APP = test +APP = test-dpdk # # all sources are stored in SRCS-y -- 2.6.3
[dpdk-dev] [PATCH v7 09/11] mk: Rename install rule as mbuild rule
"install" rule with the current dpdk behaviour change its name by mbuild. Signed-off-by: Mario Carrillo --- mk/rte.sdkinstall.mk | 8 mk/rte.sdkroot.mk| 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk index d1ff160..df16f5c 100644 --- a/mk/rte.sdkinstall.mk +++ b/mk/rte.sdkinstall.mk @@ -73,13 +73,13 @@ endif # INSTALL_CONFIGS := $(patsubst $(RTE_SRCDIR)/config/defconfig_%,%,\ $(wildcard $(RTE_SRCDIR)/config/defconfig_$(T))) -INSTALL_TARGETS := $(addsuffix _install,\ +INSTALL_TARGETS := $(addsuffix _mbuild,\ $(filter-out %~,$(INSTALL_CONFIGS))) -.PHONY: install -install: $(INSTALL_TARGETS) +.PHONY: mbuild +mbuild: $(INSTALL_TARGETS) -%_install: +%_mbuild: @echo == Installing $* $(Q)if [ ! -f $(BUILD_DIR)/$*/.config ]; then \ $(MAKE) config T=$* O=$(BUILD_DIR)/$*; \ diff --git a/mk/rte.sdkroot.mk b/mk/rte.sdkroot.mk index dd5f399..1b619b7 100644 --- a/mk/rte.sdkroot.mk +++ b/mk/rte.sdkroot.mk @@ -97,9 +97,9 @@ test fast_test ring_test mempool_test perf_test coverage: testall: $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdktestall.mk $@ -.PHONY: install install-headers install-bin install-lib install-mod \ +.PHONY: mbuild install-headers install-bin install-lib install-mod \ install-doc install-sdk install-fhs uninstall -install install-headers install-bin install-lib install-mod install-doc \ +mbuild install-headers install-bin install-lib install-mod install-doc \ install-sdk install-fhs uninstall: $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkinstall.mk $@ -- 2.6.3
[dpdk-dev] [PATCH v7 10/11] mk: Add new install rule
If "T" variable is defined, the installation process will have the current behaviour, else install rule will be called. Signed-off-by: Mario Carrillo --- mk/rte.sdkinstall.mk | 12 +++- mk/rte.sdkroot.mk| 4 ++-- 2 files changed, 13 insertions(+), 3 deletions(-) diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk index df16f5c..5195442 100644 --- a/mk/rte.sdkinstall.mk +++ b/mk/rte.sdkinstall.mk @@ -40,7 +40,6 @@ endif # target name or a name containing jokers "*". Example: # x86_64-native-*-gcc ifndef T -T=* ifneq (,$(wildcard $(RTE_OUTPUT)/.config)) prefix ?= /usr/local exec_prefix ?= $(prefix) @@ -198,6 +197,17 @@ install-fhs: install-lib install-bin install-doc install-mod cp -rf $(RTE_SDK)/tools $(DESTDIR)/$(datadir); \ echo installing: $(RTE_SDK)/tools # +# if "T" var is defined, mbuild rule will be called, else +# install-fhs rule will be called. +# +.PHONY: install +install: +ifdef T +install: mbuild +else +install: install-fhs +endif +# # uninstall: remove all built sdk # UNINSTALL_TARGETS := $(addsuffix _uninstall,\ diff --git a/mk/rte.sdkroot.mk b/mk/rte.sdkroot.mk index 1b619b7..2f8f64a 100644 --- a/mk/rte.sdkroot.mk +++ b/mk/rte.sdkroot.mk @@ -97,9 +97,9 @@ test fast_test ring_test mempool_test perf_test coverage: testall: $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdktestall.mk $@ -.PHONY: mbuild install-headers install-bin install-lib install-mod \ +.PHONY: mbuild install install-headers install-bin install-lib install-mod \ install-doc install-sdk install-fhs uninstall -mbuild install-headers install-bin install-lib install-mod install-doc \ +mbuild install install-headers install-bin install-lib install-mod install-doc \ install-sdk install-fhs uninstall: $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkinstall.mk $@ -- 2.6.3
[dpdk-dev] [PATCH v7 11/11] doc: Add information about new installation rules
Information about variables and rules behaviour is added to documentation. Signed-off-by: Mario Carrillo --- doc/build-sdk-quick.txt | 25 +- doc/guides/freebsd_gsg/build_dpdk.rst | 40 +++ doc/guides/linux_gsg/build_dpdk.rst | 38 + 3 files changed, 102 insertions(+), 1 deletion(-) diff --git a/doc/build-sdk-quick.txt b/doc/build-sdk-quick.txt index bf18b48..66f0d0e 100644 --- a/doc/build-sdk-quick.txt +++ b/doc/build-sdk-quick.txt @@ -5,10 +5,21 @@ Build commands all same as build (default rule) buildbuild in a configured directory cleanremove files but keep configuration - install build many targets (wildcard allowed) and install in DESTDIR + install if T is defined, build a target and install in DESTDIR + else call install-fhs target uninstallremove all installed targets examples build examples for given targets (T=) examples_clean clean examples for given targets (T=) +Install commands + install if T is defined, build a target and install in DESTDIR + else call install-fhs target + install-headers install headers files + install-bin install app files a dpdk tools + install-lib install libraries + install-doc install documentation + install-mod install modules + install-sdk install headers, makefiles, scripts,examples, tools and config files + install-fhs install libraries, modules, app files, nic bind files and documentation Build variables EXTRA_CPPFLAGS preprocessor options EXTRA_CFLAGS compiler options @@ -23,3 +34,15 @@ Build variables T target template (install default: *) - used with config or install format: templates in config/defconfig_* +Install variables + prefix /usr/local by default it can be overridden + exec_prefix $(prefix) + bindir $(exec_prefix)/bin by default it can be overridden + includedir $(prefix)/include by default it can be overridden + libdir $(exec_prefix)/lib by default it can be overridden + docdir $(datarootdir)/share/doc/dpdk by default it can be overridden + sdkdir $(datadir) + datadir $(datarootdir)/dpdk + datarootdir $(prefix)/share + kerneldir /lib/modules/$(uname -r)/extra/drivers/dpdk for linux + /boot/modules for BSD by default, they can be overridden diff --git a/doc/guides/freebsd_gsg/build_dpdk.rst b/doc/guides/freebsd_gsg/build_dpdk.rst index 8eff599..72826d0 100644 --- a/doc/guides/freebsd_gsg/build_dpdk.rst +++ b/doc/guides/freebsd_gsg/build_dpdk.rst @@ -136,6 +136,46 @@ The DPDK is composed of several directories: * config, tools, scripts, mk: Framework-related makefiles, scripts and configuration + +Build and install DPDK using a file hierarchy +- + +Following the next steps is possible configure, build and install specific files +according to a file hierarchy and a group of variables. + +.. code-block:: console + + make config T= + make + make + ++--++ +| install target | Description | ++==++ +|install |if T is not defined will call install-fhs install | ++--++ +|install-headers |install headers files where includedir=$(prefix)/include/dpdk | ++--++ +|install-bin |install app files a dpdk tools where bindir=$(exec_prefix)/bin | ++--++ +|install-lib |install libraries libdir=$(exec_prefix)/lib | ++--++ +|install-doc |install documentation docdir=$(datarootdir)/doc/dpdk | ++--++ +|install-mod |install modules if RTE_EXEC_ENV=linuxapp then | +| |kerneldir=/lib/modules/$(uname -r)/extra/drivers/dpdk else | +|
[dpdk-dev] 2.3 Roadmap
On Mon, 30 Nov 2015 22:53:50 + Kyle Larose wrote: > Hi Tim, > > On Mon, Nov 30, 2015 at 3:50 PM, O'Driscoll, Tim > wrote: > > > Tcpdump Support: Support for tcpdump will be added to DPDK. This will > > improve usability and debugging of DPDK applications. > > I'm curious about the proposed tcpdump support. Is there a concrete plan for > this, or is that still being looked into? Sandvine is interested in > contributing to this effort. Anything we can do to help? > > Thanks, > > Kyle We discussed an Ovscon doing a simple example of how to have a thread use named pipe support (already in tcpdump and wireshark). More complex solutions require changes to libpcap and application interaction.
[dpdk-dev] [PATCH v7 01/11] mk: Add rule for installing headers
Add hierarchy-file support to the DPDK headers,
when invoking "make install-headers" headers will
be installed in: $(DESTDIR)/$(includedir)
where includedir=$(prefix)/include/dpdk and prefix=/usr/local by
default, you can override "prefix" and "includedir" vars.
This hierarchy is based on:
http://www.freedesktop.org/software/systemd/man/file-hierarchy.html
and variables are based on:
https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
https://www.gnu.org/prep/standards/html_node/DESTDIR.html
Signed-off-by: Mario Carrillo
---
mk/rte.sdkinstall.mk | 22 +-
mk/rte.sdkroot.mk| 4 ++--
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk
index 86c98a5..a4a01cf 100644
--- a/mk/rte.sdkinstall.mk
+++ b/mk/rte.sdkinstall.mk
@@ -41,6 +41,11 @@ endif
# x86_64-native-*-gcc
ifndef T
T=*
+ifneq (,$(wildcard $(RTE_OUTPUT)/.config))
+prefix ?= /usr/local
+includedir ?= $(prefix)/include/dpdk
+HSLINKS := $(shell find $(RTE_OUTPUT)/include/ -name *.h)
+endif
endif
#
@@ -72,7 +77,22 @@ install: $(INSTALL_TARGETS)
echo "Using local configuration"; \
fi
$(Q)$(MAKE) all O=$(BUILD_DIR)/$*
-
+#
+# install headers in /usr/local/include/dpdk by default
+# "prefix" and "includedir" vars can be overridden.
+#
+.PHONY: install-headers
+install-headers:
+ @echo == Installing headers;
+ @if [ ! -z "${HSLINKS}" ]; then \
+ for HSLINK in ${HSLINKS}; do \
+ HEADER=$$(readlink -f $$HSLINK); \
+ HEADER_DIR=$$(dirname $$HSLINK | sed 's/.*include\/*//'); \
+ [ -d $(DESTDIR)/$(includedir)/$$HEADER_DIR ] || mkdir -p
$(DESTDIR)/$(includedir)/$$HEADER_DIR; \
+ cp -rf $$HEADER ${DESTDIR}/${includedir}/$$HEADER_DIR; \
+ echo installing: $$HEADER; \
+ done \
+ fi
#
# uninstall: remove all built sdk
#
diff --git a/mk/rte.sdkroot.mk b/mk/rte.sdkroot.mk
index e8423b0..8477a2b 100644
--- a/mk/rte.sdkroot.mk
+++ b/mk/rte.sdkroot.mk
@@ -97,8 +97,8 @@ test fast_test ring_test mempool_test perf_test coverage:
testall:
$(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdktestall.mk $@
-.PHONY: install uninstall
-install uninstall:
+.PHONY: install install-headers uninstall
+install install-headers uninstall:
$(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkinstall.mk $@
.PHONY: doc help
--
2.6.3
[dpdk-dev] [PATCH] i40evf: fix mac deletion when stop dev
When dev_stop is called in i40evf pmd driver, queues are switched off
to stop receiving and transmitting. But the mac address of this VF
still exists in VEB switch.
To stop the traffic from VSI level, the mac address need to be removed
too. Then the bandwidth for this SRIOV VSI can be freed.
This patch fix this issue.
Fixes: 4861cde46116 ("i40e: new poll mode driver")
Signed-off-by: Jingjing Wu
---
drivers/net/i40e/i40e_ethdev_vf.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
b/drivers/net/i40e/i40e_ethdev_vf.c
index 5c554f2..14d2a50 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -1878,7 +1878,9 @@ err_queue:
static void
i40evf_dev_stop(struct rte_eth_dev *dev)
{
+ struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct rte_intr_handle *intr_handle = &dev->pci_dev->intr_handle;
+ struct ether_addr mac_addr;
PMD_INIT_FUNC_TRACE();
@@ -1892,6 +1894,11 @@ i40evf_dev_stop(struct rte_eth_dev *dev)
rte_free(intr_handle->intr_vec);
intr_handle->intr_vec = NULL;
}
+ /* Set mac addr */
+ (void)rte_memcpy(mac_addr.addr_bytes, hw->mac.addr,
+ sizeof(mac_addr.addr_bytes));
+ /* Delete mac addr of this vf */
+ i40evf_del_mac_addr(dev, &mac_addr);
}
static int
--
2.4.0
[dpdk-dev] [PATCH] i40evf: fix mac deletion when stop dev
> -Original Message-
> From: Wu, Jingjing
> Sent: Monday, November 30, 2015 11:54 AM
> To: dev at dpdk.org
> Cc: Wu, Jingjing; Zhang, Helin; Pei, Yulong
> Subject: [PATCH] i40evf: fix mac deletion when stop dev
>
> When dev_stop is called in i40evf pmd driver, queues are switched off to
> stop receiving and transmitting. But the mac address of this VF still exists
> in
> VEB switch.
> To stop the traffic from VSI level, the mac address need to be removed too.
> Then the bandwidth for this SRIOV VSI can be freed.
> This patch fix this issue.
>
> Fixes: 4861cde46116 ("i40e: new poll mode driver")
>
> Signed-off-by: Jingjing Wu
> ---
> drivers/net/i40e/i40e_ethdev_vf.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
> b/drivers/net/i40e/i40e_ethdev_vf.c
> index 5c554f2..14d2a50 100644
> --- a/drivers/net/i40e/i40e_ethdev_vf.c
> +++ b/drivers/net/i40e/i40e_ethdev_vf.c
> @@ -1878,7 +1878,9 @@ err_queue:
> static void
> i40evf_dev_stop(struct rte_eth_dev *dev) {
> + struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data-
> >dev_private);
> struct rte_intr_handle *intr_handle = &dev->pci_dev->intr_handle;
> + struct ether_addr mac_addr;
>
> PMD_INIT_FUNC_TRACE();
>
> @@ -1892,6 +1894,11 @@ i40evf_dev_stop(struct rte_eth_dev *dev)
> rte_free(intr_handle->intr_vec);
> intr_handle->intr_vec = NULL;
> }
> + /* Set mac addr */
> + (void)rte_memcpy(mac_addr.addr_bytes, hw->mac.addr,
> + sizeof(mac_addr.addr_bytes));
Use ether_addr_copy() instead.
/Helin
> + /* Delete mac addr of this vf */
> + i40evf_del_mac_addr(dev, &mac_addr);
> }
>
> static int
> --
> 2.4.0
[dpdk-dev] [PATCH v3 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm
On Sun, Nov 29, 2015 at 06:48:29PM -0500, Jianbo Liu wrote:
> On Fri, Nov 27, 2015 at 07:04:28PM +0530, Jerin Jacob wrote:
> > Commit 42ec27a0178a causes compiling error on arm, as RTE_SCHED_VECTOR
> > does support only SSE intrinsic, so disable it till we have neon support.
> >
> > Fixes: 42ec27a0178a ("sched: enable SSE optimizations in config")
> >
> > Signed-off-by: Jerin Jacob
> > ---
> > config/common_arm64 | 1 +
> > config/defconfig_arm-armv7a-linuxapp-gcc | 1 +
> > 2 files changed, 2 insertions(+)
> >
> > diff --git a/config/common_arm64 b/config/common_arm64
> > index 5e5e303..d6a9cb9 100644
> > --- a/config/common_arm64
> > +++ b/config/common_arm64
> > @@ -46,3 +46,4 @@ CONFIG_RTE_LIBRTE_I40E_PMD=n
> > CONFIG_RTE_LIBRTE_LPM=n
> > CONFIG_RTE_LIBRTE_TABLE=n
> > CONFIG_RTE_LIBRTE_PIPELINE=n
> > +CONFIG_RTE_SCHED_VECTOR=n
> > diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc
> > b/config/defconfig_arm-armv7a-linuxapp-gcc
> > index 82143af..9924ff9 100644
> > --- a/config/defconfig_arm-armv7a-linuxapp-gcc
> > +++ b/config/defconfig_arm-armv7a-linuxapp-gcc
> > @@ -57,6 +57,7 @@ CONFIG_RTE_LIBRTE_ACL=n
> > CONFIG_RTE_LIBRTE_LPM=n
> > CONFIG_RTE_LIBRTE_TABLE=n
> > CONFIG_RTE_LIBRTE_PIPELINE=n
> > +CONFIG_RTE_SCHED_VECTOR=n
> >
> > # cannot use those on ARM
> > CONFIG_RTE_KNI_KMOD=n
> > --
> > 2.1.0
> >
>
> Hi Jerin,
Hi Jianbo, Thanks for the review.
Looking forward to seeing contributions to DPDK-ARM.
We definitely need more hands to make best DPDK-ARM port.
> In this way, we still have to modify two files each time a new feature
> is added but not verified on ARM architectures.
> Since disabling those drivers and libs are common for both armv7 and
> armv8, can you put them in one config file, for example: common_arm?
I initially thought of making it a single common_arm file, Then
later I realized that it may not be worth as,
1) If a new feature added to DPDK which has the dependency on SSE then
implementer has to disable on "n" platforms(tile, powerpc..).By unifying
single arm config will make it "n-1" so it's like "n" vs "n-1" not "n"
vs "2n"
2) AFAIK, PCI NIC PMD's are not yet supported in ARMv7 platform yet
unlike ARMv8.
Till we have PCI NIC PMD support, armv7 config needs to be updated
for each and every new PMD inclusion.
3) neon capabilities are bit different in ARMv7 and ARMv8.
For instance, "vqtbl1q_u8" neon intrinsics is not defined in ARMv7 which used
in implementing ACL-NEON. i.e Need additional efforts to extend
the armv8 neon code to armv7(or vice versa).So it's better to
have fine control on the config file to enable selective features
3) anyway we may need common_armv8 file to address the "IMPLEMENTATION
DEFINED" parts of the armv8 specific in future, like frequency at cntvct_el0
runs ? optional features like armv8 crypto instruction support or not?
It's armv8 v1 or v2 ? atomic instruction support for not? its a long
list
4)I would like to see ARM configs as different config like i686, X86_64
in DPDK
> It is not like common_arm64, which is solely for armv8 platform.
> Actually, the arm64 common config is defconfig_arm64-armv8a-linuxapp-gcc
I thought so, Then I realized that we may have
FreeBSD, arm compiler, clang, llvm support in future.
> you can include it in the thunderx or xgene1 config files respectively,
> and overriding some special config if needed.
Agree. existing patch addresses this
>
> On the other hand, If we support the features in the future by
> replacing SSE intrinsic with NEON, we just need to remove the lines in one
> place.
See point 3 above,
I feel rather than coming with the framework to fix the exceptions it's
better to fix the exceptions its self.
I am planning to send out next patch by today for supporting
CONFIG_RTE_LIBRTE_LPM,CONFIG_RTE_LIBRTE_TABLE,CONFIG_RTE_LIBRTE_PIPELINE.
i.e only a few entries will be common. Please find below the list,
the reason for setting as "n" for armv7 and armv8 is different.
lack of PCI PMD supports vs SIMD support.
CONFIG_RTE_IXGBE_INC_VECTOR=n
CONFIG_RTE_LIBRTE_VIRTIO_PMD=n
CONFIG_RTE_LIBRTE_IVSHMEM=n
CONFIG_RTE_LIBRTE_FM10K_PMD=n
CONFIG_RTE_LIBRTE_I40E_PMD=n
- Jerin
>
> Regards,
> Jianbo
[dpdk-dev] [PATCH] i40evf: fix mac deletion when stop dev
> > + /* Set mac addr */ > > + (void)rte_memcpy(mac_addr.addr_bytes, hw->mac.addr, > > + sizeof(mac_addr.addr_bytes)); > Use ether_addr_copy() instead. > > /Helin Thanks. But the types of mac_addr and hw->mac are different, cannot use ether_addr_copy. Thanks Jingjing
[dpdk-dev] [PATCH] hash: add rte_hash_set_cmp_func() function.
Hi,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Yu Nemo Wenbin
> Sent: Friday, November 27, 2015 2:11 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] hash: add rte_hash_set_cmp_func() function.
>
> Give user a chance to customize the hash key compare function.
> The default rte_hash_cmp_eq function is set in the rte_hash_create
> function, but these builtin ones may not be good enough, so the user
> may call this to override the default one.
>
> Signed-off-by: Yu Nemo Wenbin
> ---
> lib/librte_hash/rte_cuckoo_hash.c| 7 +--
> lib/librte_hash/rte_hash.h | 15 +++
> lib/librte_hash/rte_hash_version.map | 7 +++
> 3 files changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/lib/librte_hash/rte_cuckoo_hash.c
> b/lib/librte_hash/rte_cuckoo_hash.c
> index 88f77c3..2ccb81c 100644
> --- a/lib/librte_hash/rte_cuckoo_hash.c
> +++ b/lib/librte_hash/rte_cuckoo_hash.c
> @@ -102,8 +102,6 @@ EAL_REGISTER_TAILQ(rte_hash_tailq)
>
> #define LCORE_CACHE_SIZE 8
>
> -typedef int (*rte_hash_cmp_eq_t)(const void *key1, const void *key2,
> size_t key_len);
> -
> struct lcore_cache {
> unsigned len; /**< Cache len */
> void *objs[LCORE_CACHE_SIZE]; /**< Cache objects */
> @@ -187,6 +185,11 @@ rte_hash_find_existing(const char *name)
> return h;
> }
>
> +void rte_hash_set_cmp_func(struct rte_hash *h, rte_hash_cmp_eq_t
> func)
> +{
> +h->rte_hash_cmp_eq = func;
> +}
> +
> struct rte_hash *
> rte_hash_create(const struct rte_hash_parameters *params)
> {
> diff --git a/lib/librte_hash/rte_hash.h b/lib/librte_hash/rte_hash.h
> index b678766..dfca5ef 100644
> --- a/lib/librte_hash/rte_hash.h
> +++ b/lib/librte_hash/rte_hash.h
> @@ -66,6 +66,9 @@ typedef uint32_t hash_sig_t;
> typedef uint32_t (*rte_hash_function)(const void *key, uint32_t key_len,
> uint32_t init_val);
>
> +/** Type of function used to compare the hash key. */
> +typedef int (*rte_hash_cmp_eq_t)(const void *key1, const void *key2,
> size_t key_len);
> +
> /**
> * Parameters used when creating the hash table.
> */
> @@ -104,6 +107,18 @@ struct rte_hash *
> rte_hash_create(const struct rte_hash_parameters *params);
>
> /**
> + * Set the rte_hash_set_cmp_func.
> + * Set a new hash compare function other than the default one.
> + *
> + * @note Function pointer does not work with multi-process, so don't use
> it
> + * in multi-process mode.
> + *
> + * @param h
> + * Hash table to reset
> + */
> +void rte_hash_set_cmp_func(struct rte_hash *h, rte_hash_cmp_eq_t
> func);
> +
> +/**
> * Find an existing hash table object and return a pointer to it.
> *
> * @param name
> diff --git a/lib/librte_hash/rte_hash_version.map
> b/lib/librte_hash/rte_hash_version.map
> index 906c8ad..1aa94f9 100644
> --- a/lib/librte_hash/rte_hash_version.map
> +++ b/lib/librte_hash/rte_hash_version.map
> @@ -32,3 +32,10 @@ DPDK_2.1 {
> rte_hash_reset;
>
> } DPDK_2.0;
> +
> +DPDK_2.2 {
> + global:
> +
> + rte_hash_set_cmp_func;
> +
> +} DPDK_2.1;
> --
> 1.9.1
Acked-by: Pablo de Lara
Although, you needed to send this as a v2 (or v3?)!
[dpdk-dev] [PATCH v3 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm
On Mon, Nov 30, 2015 at 11:17:52AM +0530, Jerin Jacob wrote:
> On Sun, Nov 29, 2015 at 06:48:29PM -0500, Jianbo Liu wrote:
> > On Fri, Nov 27, 2015 at 07:04:28PM +0530, Jerin Jacob wrote:
> > > Commit 42ec27a0178a causes compiling error on arm, as RTE_SCHED_VECTOR
> > > does support only SSE intrinsic, so disable it till we have neon support.
> > >
> > > Fixes: 42ec27a0178a ("sched: enable SSE optimizations in config")
> > >
> > > Signed-off-by: Jerin Jacob
> > > ---
> > > config/common_arm64 | 1 +
> > > config/defconfig_arm-armv7a-linuxapp-gcc | 1 +
> > > 2 files changed, 2 insertions(+)
> > >
> > > diff --git a/config/common_arm64 b/config/common_arm64
> > > index 5e5e303..d6a9cb9 100644
> > > --- a/config/common_arm64
> > > +++ b/config/common_arm64
> > > @@ -46,3 +46,4 @@ CONFIG_RTE_LIBRTE_I40E_PMD=n
> > > CONFIG_RTE_LIBRTE_LPM=n
> > > CONFIG_RTE_LIBRTE_TABLE=n
> > > CONFIG_RTE_LIBRTE_PIPELINE=n
> > > +CONFIG_RTE_SCHED_VECTOR=n
> > > diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc
> > > b/config/defconfig_arm-armv7a-linuxapp-gcc
> > > index 82143af..9924ff9 100644
> > > --- a/config/defconfig_arm-armv7a-linuxapp-gcc
> > > +++ b/config/defconfig_arm-armv7a-linuxapp-gcc
> > > @@ -57,6 +57,7 @@ CONFIG_RTE_LIBRTE_ACL=n
> > > CONFIG_RTE_LIBRTE_LPM=n
> > > CONFIG_RTE_LIBRTE_TABLE=n
> > > CONFIG_RTE_LIBRTE_PIPELINE=n
> > > +CONFIG_RTE_SCHED_VECTOR=n
> > >
> > > # cannot use those on ARM
> > > CONFIG_RTE_KNI_KMOD=n
> > > --
> > > 2.1.0
> > >
> >
> > Hi Jerin,
>
> Hi Jianbo, Thanks for the review.
> Looking forward to seeing contributions to DPDK-ARM.
> We definitely need more hands to make best DPDK-ARM port.
>
> > In this way, we still have to modify two files each time a new feature
> > is added but not verified on ARM architectures.
> > Since disabling those drivers and libs are common for both armv7 and
> > armv8, can you put them in one config file, for example: common_arm?
>
> I initially thought of making it a single common_arm file, Then
> later I realized that it may not be worth as,
>
> 1) If a new feature added to DPDK which has the dependency on SSE then
> implementer has to disable on "n" platforms(tile, powerpc..).By unifying
> single arm config will make it "n-1" so it's like "n" vs "n-1" not "n"
> vs "2n"
I'm talking about your patch, which is for ARM platform only. And the
two files we need to modify are armv7 and armv8 configs.
If you want to include other platforms, your patch is still incomplete :)
>
> 2) AFAIK, PCI NIC PMD's are not yet supported in ARMv7 platform yet
> unlike ARMv8.
> Till we have PCI NIC PMD support, armv7 config needs to be updated
> for each and every new PMD inclusion.
>
> 3) neon capabilities are bit different in ARMv7 and ARMv8.
> For instance, "vqtbl1q_u8" neon intrinsics is not defined in ARMv7 which used
> in implementing ACL-NEON. i.e Need additional efforts to extend
> the armv8 neon code to armv7(or vice versa).So it's better to
> have fine control on the config file to enable selective features
>
The differences between ARMv7 and ARMv8 can't justify we only add new
config for ARMv8. And this file is trying to disable drivers and libs
which is not supported on ARM platforms for now.
> 3) anyway we may need common_armv8 file to address the "IMPLEMENTATION
> DEFINED" parts of the armv8 specific in future, like frequency at cntvct_el0
> runs ? optional features like armv8 crypto instruction support or not?
> It's armv8 v1 or v2 ? atomic instruction support for not? its a long
> list
>
I think these "IMPLEMENTATION DEFINED" features should be configured
in the different platform (machine) config files. Can this
common_arm64 solve your concern?
> 4)I would like to see ARM configs as different config like i686, X86_64
> in DPDK
>
Basically, we need to use the default common_linux/bsd to enable the
new-added features in DPDK.
>
> > It is not like common_arm64, which is solely for armv8 platform.
> > Actually, the arm64 common config is defconfig_arm64-armv8a-linuxapp-gcc
>
> I thought so, Then I realized that we may have
> FreeBSD, arm compiler, clang, llvm support in future.
>
> > you can include it in the thunderx or xgene1 config files respectively,
> > and overriding some special config if needed.
>
> Agree. existing patch addresses this
>
If there exists a defconfig_arm64-armv8a-linuxapp-gcc, why needs to
add a new file(common_arm64) in your patch?
The defconfig_arm64-armv8a-xxx-xxx can be treated as a config for a
common ARMv8 platform, and one which other specific ARMv8 platforms
can base on.
> >
> > On the other hand, If we support the features in the future by
> > replacing SSE intrinsic with NEON, we just need to remove the lines in one
> > place.
>
> See point 3 above,
>
> I feel rather than coming with the framework to fix the exceptions it's
> better to fix the exceptions its self.
> I am planning to send out next patch by today for supporting
> CONFIG_RTE_LIBRTE_LPM,CONFIG_RT
[dpdk-dev] [PATCH v3 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm
On Mon, Nov 30, 2015 at 12:03:21PM -0500, Jianbo Liu wrote:
> On Mon, Nov 30, 2015 at 11:17:52AM +0530, Jerin Jacob wrote:
> > On Sun, Nov 29, 2015 at 06:48:29PM -0500, Jianbo Liu wrote:
> > > On Fri, Nov 27, 2015 at 07:04:28PM +0530, Jerin Jacob wrote:
> > > > Commit 42ec27a0178a causes compiling error on arm, as RTE_SCHED_VECTOR
> > > > does support only SSE intrinsic, so disable it till we have neon
> > > > support.
> > > >
> > > > Fixes: 42ec27a0178a ("sched: enable SSE optimizations in config")
> > > >
> > > > Signed-off-by: Jerin Jacob
> > > > ---
> > > > config/common_arm64 | 1 +
> > > > config/defconfig_arm-armv7a-linuxapp-gcc | 1 +
> > > > 2 files changed, 2 insertions(+)
> > > >
> > > > diff --git a/config/common_arm64 b/config/common_arm64
> > > > index 5e5e303..d6a9cb9 100644
> > > > --- a/config/common_arm64
> > > > +++ b/config/common_arm64
> > > > @@ -46,3 +46,4 @@ CONFIG_RTE_LIBRTE_I40E_PMD=n
> > > > CONFIG_RTE_LIBRTE_LPM=n
> > > > CONFIG_RTE_LIBRTE_TABLE=n
> > > > CONFIG_RTE_LIBRTE_PIPELINE=n
> > > > +CONFIG_RTE_SCHED_VECTOR=n
> > > > diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc
> > > > b/config/defconfig_arm-armv7a-linuxapp-gcc
> > > > index 82143af..9924ff9 100644
> > > > --- a/config/defconfig_arm-armv7a-linuxapp-gcc
> > > > +++ b/config/defconfig_arm-armv7a-linuxapp-gcc
> > > > @@ -57,6 +57,7 @@ CONFIG_RTE_LIBRTE_ACL=n
> > > > CONFIG_RTE_LIBRTE_LPM=n
> > > > CONFIG_RTE_LIBRTE_TABLE=n
> > > > CONFIG_RTE_LIBRTE_PIPELINE=n
> > > > +CONFIG_RTE_SCHED_VECTOR=n
> > > >
> > > > # cannot use those on ARM
> > > > CONFIG_RTE_KNI_KMOD=n
> > > > --
> > > > 2.1.0
> > > >
> > >
> > > Hi Jerin,
> >
> > Hi Jianbo, Thanks for the review.
> > Looking forward to seeing contributions to DPDK-ARM.
> > We definitely need more hands to make best DPDK-ARM port.
> >
> > > In this way, we still have to modify two files each time a new feature
> > > is added but not verified on ARM architectures.
> > > Since disabling those drivers and libs are common for both armv7 and
> > > armv8, can you put them in one config file, for example: common_arm?
> >
> > I initially thought of making it a single common_arm file, Then
> > later I realized that it may not be worth as,
> >
> > 1) If a new feature added to DPDK which has the dependency on SSE then
> > implementer has to disable on "n" platforms(tile, powerpc..).By unifying
> > single arm config will make it "n-1" so it's like "n" vs "n-1" not "n"
> > vs "2n"
>
> I'm talking about your patch, which is for ARM platform only. And the
> two files we need to modify are armv7 and armv8 configs.
> If you want to include other platforms, your patch is still incomplete :)
>
That was the reply for the concern you have raised for the new feature.
Not specific to my patch. My patch is complete, as I have
checked other platforms before sending the patch
they have already disabled the sched library :-)
> >
> > 2) AFAIK, PCI NIC PMD's are not yet supported in ARMv7 platform yet
> > unlike ARMv8.
> > Till we have PCI NIC PMD support, armv7 config needs to be updated
> > for each and every new PMD inclusion.
> >
> > 3) neon capabilities are bit different in ARMv7 and ARMv8.
> > For instance, "vqtbl1q_u8" neon intrinsics is not defined in ARMv7 which
> > used
> > in implementing ACL-NEON. i.e Need additional efforts to extend
> > the armv8 neon code to armv7(or vice versa).So it's better to
> > have fine control on the config file to enable selective features
> >
>
> The differences between ARMv7 and ARMv8 can't justify we only add new
> config for ARMv8. And this file is trying to disable drivers and libs
> which is not supported on ARM platforms for now.
>
I thought difference and point 3 should justify the need for different config.
No?
> > 3) anyway we may need common_armv8 file to address the "IMPLEMENTATION
> > DEFINED" parts of the armv8 specific in future, like frequency at cntvct_el0
> > runs ? optional features like armv8 crypto instruction support or not?
> > It's armv8 v1 or v2 ? atomic instruction support for not? its a long
> > list
> >
>
> I think these "IMPLEMENTATION DEFINED" features should be configured
> in the different platform (machine) config files. Can this
> common_arm64 solve your concern?
Yes, "IMPLEMENTATION DEFINED" features of armv8(default behavior in
common_arm64). I think it makes sense not mix with armv7.
>
> > 4)I would like to see ARM configs as different config like i686, X86_64
> > in DPDK
> >
>
> Basically, we need to use the default common_linux/bsd to enable the
> new-added features in DPDK.
>
> >
> > > It is not like common_arm64, which is solely for armv8 platform.
> > > Actually, the arm64 common config is defconfig_arm64-armv8a-linuxapp-gcc
> >
> > I thought so, Then I realized that we may have
> > FreeBSD, arm compiler, clang, llvm support in future.
> >
> > > you can include it in the thunderx or xgene1 config files respectively,
> > > and overriding some sp
[dpdk-dev] [PATCH v10 0/8] support for netronome nfp-6xxx card
This patchset adds a new PMD for Netronome nfp-6xxx card. Just PCI Virtual Functions support. Using this PMD requires previous Netronome BSP installation. v10: - Getting rid of __u8 usage - Squashing last two patches in one v9: - - Adding flag RTE_PCI_DRV_INTR_LSC - Makefile changes for compilation as a shared library - Adding map file for linker version script info v8: - removing remaining unnecessary flags to PMD Makefile v7: - Adding support for link status changes interrupts. - removing unnecessary flags when compiling the PMD. v6: - Making each patch compilable. v5: - Splitting up patches per functionality. v4: - Getting rid of nfp_uio. Just submitting PMD. - Removing LSC interrupt support. v3: - Making all patches independent for applying and building. - changing commits messages following standard. v2: - Code style changes based on checkpatch.pl and DPDK style guide. - Documentation changes using the right rst format. - Moving the documentation files to a new patch file. - Adding info to MAINTAINERS and release files. Alejandro Lucero (8): nfp: basic initialization nfp: adding rx/tx functionality nfp: adding rss nfp: adding stats nfp: adding link functionality nfp: adding extra functionality nfp: link status change interrupt support nfp: adding nic guide MAINTAINERS |4 + config/common_linuxapp |6 + doc/guides/nics/index.rst |1 + doc/guides/nics/nfp.rst | 265 doc/guides/rel_notes/release_2_2.rst|3 + drivers/net/Makefile|1 + drivers/net/nfp/Makefile| 56 + drivers/net/nfp/nfp_net.c | 2499 +++ drivers/net/nfp/nfp_net_ctrl.h | 324 drivers/net/nfp/nfp_net_logs.h | 75 + drivers/net/nfp/nfp_net_pmd.h | 453 ++ drivers/net/nfp/rte_pmd_nfp_version.map |3 + mk/rte.app.mk |1 + 13 files changed, 3691 insertions(+) create mode 100644 doc/guides/nics/nfp.rst create mode 100644 drivers/net/nfp/Makefile create mode 100644 drivers/net/nfp/nfp_net.c create mode 100644 drivers/net/nfp/nfp_net_ctrl.h create mode 100644 drivers/net/nfp/nfp_net_logs.h create mode 100644 drivers/net/nfp/nfp_net_pmd.h create mode 100644 drivers/net/nfp/rte_pmd_nfp_version.map -- 1.7.9.5
[dpdk-dev] [PATCH v10 3/8] nfp: adding rss
Signed-off-by: Alejandro Lucero
Signed-off-by: Rolf Neugebauer
---
drivers/net/nfp/nfp_net.c | 218 +
1 file changed, 218 insertions(+)
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index 0d85fa4..a9be403 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -1501,12 +1501,230 @@ xmit_end:
return i;
}
+/* Update Redirection Table(RETA) of Receive Side Scaling of Ethernet device */
+static int
+nfp_net_reta_update(struct rte_eth_dev *dev,
+ struct rte_eth_rss_reta_entry64 *reta_conf,
+ uint16_t reta_size)
+{
+ uint32_t reta, mask;
+ int i, j;
+ int idx, shift;
+ uint32_t update;
+ struct nfp_net_hw *hw =
+ NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+ if (!(hw->ctrl & NFP_NET_CFG_CTRL_RSS))
+ return -EINVAL;
+
+ if (reta_size != NFP_NET_CFG_RSS_ITBL_SZ) {
+ RTE_LOG(ERR, PMD, "The size of hash lookup table configured "
+ "(%d) doesn't match the number hardware can supported "
+ "(%d)\n", reta_size, NFP_NET_CFG_RSS_ITBL_SZ);
+ return -EINVAL;
+ }
+
+ /*
+* Update Redirection Table. There are 128 8bit-entries which can be
+* manage as 32 32bit-entries
+*/
+ for (i = 0; i < reta_size; i += 4) {
+ /* Handling 4 RSS entries per loop */
+ idx = i / RTE_RETA_GROUP_SIZE;
+ shift = i % RTE_RETA_GROUP_SIZE;
+ mask = (uint8_t)((reta_conf[idx].mask >> shift) & 0xF);
+
+ if (!mask)
+ continue;
+
+ reta = 0;
+ /* If all 4 entries were set, don't need read RETA register */
+ if (mask != 0xF)
+ reta = nn_cfg_readl(hw, NFP_NET_CFG_RSS_ITBL + i);
+
+ for (j = 0; j < 4; j++) {
+ if (!(mask & (0x1 << j)))
+ continue;
+ if (mask != 0xF)
+ /* Clearing the entry bits */
+ reta &= ~(0xFF << (8 * j));
+ reta |= reta_conf[idx].reta[shift + j] << (8 * j);
+ }
+ nn_cfg_writel(hw, NFP_NET_CFG_RSS_ITBL + shift, reta);
+ }
+
+ update = NFP_NET_CFG_UPDATE_RSS;
+
+ if (nfp_net_reconfig(hw, hw->ctrl, update) < 0)
+ return -EIO;
+
+ return 0;
+}
+
+ /* Query Redirection Table(RETA) of Receive Side Scaling of Ethernet device.
*/
+static int
+nfp_net_reta_query(struct rte_eth_dev *dev,
+ struct rte_eth_rss_reta_entry64 *reta_conf,
+ uint16_t reta_size)
+{
+ uint8_t i, j, mask;
+ int idx, shift;
+ uint32_t reta;
+ struct nfp_net_hw *hw;
+
+ hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+ if (!(hw->ctrl & NFP_NET_CFG_CTRL_RSS))
+ return -EINVAL;
+
+ if (reta_size != NFP_NET_CFG_RSS_ITBL_SZ) {
+ RTE_LOG(ERR, PMD, "The size of hash lookup table configured "
+ "(%d) doesn't match the number hardware can supported "
+ "(%d)\n", reta_size, NFP_NET_CFG_RSS_ITBL_SZ);
+ return -EINVAL;
+ }
+
+ /*
+* Reading Redirection Table. There are 128 8bit-entries which can be
+* manage as 32 32bit-entries
+*/
+ for (i = 0; i < reta_size; i += 4) {
+ /* Handling 4 RSS entries per loop */
+ idx = i / RTE_RETA_GROUP_SIZE;
+ shift = i % RTE_RETA_GROUP_SIZE;
+ mask = (uint8_t)((reta_conf[idx].mask >> shift) & 0xF);
+
+ if (!mask)
+ continue;
+
+ reta = nn_cfg_readl(hw, NFP_NET_CFG_RSS_ITBL + shift);
+ for (j = 0; j < 4; j++) {
+ if (!(mask & (0x1 << j)))
+ continue;
+ reta_conf->reta[shift + j] =
+ (uint8_t)((reta >> (8 * j)) & 0xF);
+ }
+ }
+ return 0;
+}
+
+static int
+nfp_net_rss_hash_update(struct rte_eth_dev *dev,
+ struct rte_eth_rss_conf *rss_conf)
+{
+ uint32_t update;
+ uint32_t cfg_rss_ctrl = 0;
+ uint8_t key;
+ uint64_t rss_hf;
+ int i;
+ struct nfp_net_hw *hw;
+
+ hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+ rss_hf = rss_conf->rss_hf;
+
+ /* Checking if RSS is enabled */
+ if (!(hw->ctrl & NFP_NET_CFG_CTRL_RSS)) {
+ if (rss_hf != 0) { /* Enable RSS? */
+ RTE_LOG(ERR, PMD, "RSS unsupported\n");
+ return -EINVAL;
+ }
+ return 0; /* Nothing to do */
+ }
+
+ if (rss_conf->rss_key_len > NFP_NET_CFG_RSS_KEY_
[dpdk-dev] [PATCH v10 4/8] nfp: adding stats
Signed-off-by: Alejandro Lucero
Signed-off-by: Rolf Neugebauer
---
drivers/net/nfp/nfp_net.c | 179 +
1 file changed, 179 insertions(+)
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index a9be403..0912064 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -90,6 +90,9 @@ static int nfp_net_tx_queue_setup(struct rte_eth_dev *dev,
uint16_t queue_idx,
uint16_t nb_desc, unsigned int socket_id,
const struct rte_eth_txconf *tx_conf);
static int nfp_net_start(struct rte_eth_dev *dev);
+static void nfp_net_stats_get(struct rte_eth_dev *dev,
+ struct rte_eth_stats *stats);
+static void nfp_net_stats_reset(struct rte_eth_dev *dev);
static void nfp_net_stop(struct rte_eth_dev *dev);
static uint16_t nfp_net_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
uint16_t nb_pkts);
@@ -679,6 +682,177 @@ nfp_net_close(struct rte_eth_dev *dev)
*/
}
+static void
+nfp_net_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
+{
+ int i;
+ struct nfp_net_hw *hw;
+ struct rte_eth_stats nfp_dev_stats;
+
+ hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+ /* RTE_ETHDEV_QUEUE_STAT_CNTRS default value is 16 */
+
+ /* reading per RX ring stats */
+ for (i = 0; i < dev->data->nb_rx_queues; i++) {
+ if (i == RTE_ETHDEV_QUEUE_STAT_CNTRS)
+ break;
+
+ nfp_dev_stats.q_ipackets[i] =
+ nn_cfg_readq(hw, NFP_NET_CFG_RXR_STATS(i));
+
+ nfp_dev_stats.q_ipackets[i] -=
+ hw->eth_stats_base.q_ipackets[i];
+
+ nfp_dev_stats.q_ibytes[i] =
+ nn_cfg_readq(hw, NFP_NET_CFG_RXR_STATS(i) + 0x8);
+
+ nfp_dev_stats.q_ibytes[i] -=
+ hw->eth_stats_base.q_ibytes[i];
+ }
+
+ /* reading per TX ring stats */
+ for (i = 0; i < dev->data->nb_tx_queues; i++) {
+ if (i == RTE_ETHDEV_QUEUE_STAT_CNTRS)
+ break;
+
+ nfp_dev_stats.q_opackets[i] =
+ nn_cfg_readq(hw, NFP_NET_CFG_TXR_STATS(i));
+
+ nfp_dev_stats.q_opackets[i] -=
+ hw->eth_stats_base.q_opackets[i];
+
+ nfp_dev_stats.q_obytes[i] =
+ nn_cfg_readq(hw, NFP_NET_CFG_TXR_STATS(i) + 0x8);
+
+ nfp_dev_stats.q_obytes[i] -=
+ hw->eth_stats_base.q_obytes[i];
+ }
+
+ nfp_dev_stats.ipackets =
+ nn_cfg_readq(hw, NFP_NET_CFG_STATS_RX_FRAMES);
+
+ nfp_dev_stats.ipackets -= hw->eth_stats_base.ipackets;
+
+ nfp_dev_stats.ibytes =
+ nn_cfg_readq(hw, NFP_NET_CFG_STATS_RX_OCTETS);
+
+ nfp_dev_stats.ibytes -= hw->eth_stats_base.ibytes;
+
+ nfp_dev_stats.opackets =
+ nn_cfg_readq(hw, NFP_NET_CFG_STATS_TX_FRAMES);
+
+ nfp_dev_stats.opackets -= hw->eth_stats_base.opackets;
+
+ nfp_dev_stats.obytes =
+ nn_cfg_readq(hw, NFP_NET_CFG_STATS_TX_OCTETS);
+
+ nfp_dev_stats.obytes -= hw->eth_stats_base.obytes;
+
+ nfp_dev_stats.imcasts =
+ nn_cfg_readq(hw, NFP_NET_CFG_STATS_RX_MC_FRAMES);
+
+ nfp_dev_stats.imcasts -= hw->eth_stats_base.imcasts;
+
+ /* reading general device stats */
+ nfp_dev_stats.ierrors =
+ nn_cfg_readq(hw, NFP_NET_CFG_STATS_RX_ERRORS);
+
+ nfp_dev_stats.ierrors -= hw->eth_stats_base.ierrors;
+
+ nfp_dev_stats.oerrors =
+ nn_cfg_readq(hw, NFP_NET_CFG_STATS_TX_ERRORS);
+
+ nfp_dev_stats.oerrors -= hw->eth_stats_base.oerrors;
+
+ /* Multicast frames received */
+ nfp_dev_stats.imcasts =
+ nn_cfg_readq(hw, NFP_NET_CFG_STATS_RX_MC_FRAMES);
+
+ nfp_dev_stats.imcasts -= hw->eth_stats_base.imcasts;
+
+ /* RX ring mbuf allocation failures */
+ nfp_dev_stats.rx_nombuf = dev->data->rx_mbuf_alloc_failed;
+
+ nfp_dev_stats.imissed =
+ nn_cfg_readq(hw, NFP_NET_CFG_STATS_RX_DISCARDS);
+
+ nfp_dev_stats.imissed -= hw->eth_stats_base.imissed;
+
+ if (stats)
+ memcpy(stats, &nfp_dev_stats, sizeof(*stats));
+}
+
+static void
+nfp_net_stats_reset(struct rte_eth_dev *dev)
+{
+ int i;
+ struct nfp_net_hw *hw;
+
+ hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+ /*
+* hw->eth_stats_base records the per counter starting point.
+* Lets update it now
+*/
+
+ /* reading per RX ring stats */
+ for (i = 0; i < dev->data->nb_rx_queues; i++) {
+ if (i == RTE_ETHDEV_QUEUE_STAT_CNTRS)
+ break;
+
+ hw->eth_stats_base.q_ipackets[i] =
+ nn_cfg_readq(hw, NFP_NET_CFG_RXR_STAT
[dpdk-dev] [PATCH v10 5/8] nfp: adding link functionality
Signed-off-by: Alejandro Lucero
Signed-off-by: Rolf Neugebauer
---
drivers/net/nfp/nfp_net.c | 96 +
1 file changed, 96 insertions(+)
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index 0912064..7c82e96 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -74,6 +74,7 @@
static void nfp_net_close(struct rte_eth_dev *dev);
static int nfp_net_configure(struct rte_eth_dev *dev);
static int nfp_net_init(struct rte_eth_dev *eth_dev);
+static int nfp_net_link_update(struct rte_eth_dev *dev, int wait_to_complete);
static int nfp_net_rx_fill_freelist(struct nfp_net_rxq *rxq);
static uint32_t nfp_net_rx_queue_count(struct rte_eth_dev *dev,
uint16_t queue_idx);
@@ -226,6 +227,57 @@ ring_dma_zone_reserve(struct rte_eth_dev *dev, const char
*ring_name,
NFP_MEMZONE_ALIGN);
}
+/*
+ * Atomically reads link status information from global structure rte_eth_dev.
+ *
+ * @param dev
+ * - Pointer to the structure rte_eth_dev to read from.
+ * - Pointer to the buffer to be saved with the link status.
+ *
+ * @return
+ * - On success, zero.
+ * - On failure, negative value.
+ */
+static inline int
+nfp_net_dev_atomic_read_link_status(struct rte_eth_dev *dev,
+ struct rte_eth_link *link)
+{
+ struct rte_eth_link *dst = link;
+ struct rte_eth_link *src = &dev->data->dev_link;
+
+ if (rte_atomic64_cmpset((uint64_t *)dst, *(uint64_t *)dst,
+ *(uint64_t *)src) == 0)
+ return -1;
+
+ return 0;
+}
+
+/*
+ * Atomically writes the link status information into global
+ * structure rte_eth_dev.
+ *
+ * @param dev
+ * - Pointer to the structure rte_eth_dev to read from.
+ * - Pointer to the buffer to be saved with the link status.
+ *
+ * @return
+ * - On success, zero.
+ * - On failure, negative value.
+ */
+static inline int
+nfp_net_dev_atomic_write_link_status(struct rte_eth_dev *dev,
+struct rte_eth_link *link)
+{
+ struct rte_eth_link *dst = &dev->data->dev_link;
+ struct rte_eth_link *src = link;
+
+ if (rte_atomic64_cmpset((uint64_t *)dst, *(uint64_t *)dst,
+ *(uint64_t *)src) == 0)
+ return -1;
+
+ return 0;
+}
+
static void
nfp_net_rx_queue_release_mbufs(struct nfp_net_rxq *rxq)
{
@@ -682,6 +734,49 @@ nfp_net_close(struct rte_eth_dev *dev)
*/
}
+/*
+ * return 0 means link status changed, -1 means not changed
+ *
+ * Wait to complete is needed as it can take up to 9 seconds to get the Link
+ * status.
+ */
+static int
+nfp_net_link_update(struct rte_eth_dev *dev, __rte_unused int wait_to_complete)
+{
+ struct nfp_net_hw *hw;
+ struct rte_eth_link link, old;
+ uint32_t nn_link_status;
+
+ PMD_DRV_LOG(DEBUG, "Link update\n");
+
+ hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+ memset(&old, 0, sizeof(old));
+ nfp_net_dev_atomic_read_link_status(dev, &old);
+
+ nn_link_status = nn_cfg_readl(hw, NFP_NET_CFG_STS);
+
+ memset(&link, 0, sizeof(struct rte_eth_link));
+
+ if (nn_link_status & NFP_NET_CFG_STS_LINK)
+ link.link_status = 1;
+
+ link.link_duplex = ETH_LINK_FULL_DUPLEX;
+ /* Other cards can limit the tx and rx rate per VF */
+ link.link_speed = ETH_LINK_SPEED_40G;
+
+ if (old.link_status != link.link_status) {
+ nfp_net_dev_atomic_write_link_status(dev, &link);
+ if (link.link_status)
+ PMD_DRV_LOG(INFO, "NIC Link is Up\n");
+ else
+ PMD_DRV_LOG(INFO, "NIC Link is Down\n");
+ return 0;
+ }
+
+ return -1;
+}
+
static void
nfp_net_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
{
@@ -1895,6 +1990,7 @@ static struct eth_dev_ops nfp_net_eth_dev_ops = {
.dev_start = nfp_net_start,
.dev_stop = nfp_net_stop,
.dev_close = nfp_net_close,
+ .link_update= nfp_net_link_update,
.stats_get = nfp_net_stats_get,
.stats_reset= nfp_net_stats_reset,
.reta_update= nfp_net_reta_update,
--
1.7.9.5
[dpdk-dev] [PATCH v10 7/8] nfp: link status change interrupt support
Signed-off-by: Alejandro Lucero
Signed-off-by: Rolf Neugebauer
---
drivers/net/nfp/nfp_net.c | 123 +
1 file changed, 123 insertions(+)
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index ff9a8d6..bc2089f 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -73,6 +73,9 @@
/* Prototypes */
static void nfp_net_close(struct rte_eth_dev *dev);
static int nfp_net_configure(struct rte_eth_dev *dev);
+static void nfp_net_dev_interrupt_handler(struct rte_intr_handle *handle,
+ void *param);
+static void nfp_net_dev_interrupt_delayed_handler(void *param);
static int nfp_net_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu);
static void nfp_net_infos_get(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info);
@@ -731,6 +734,7 @@ nfp_net_close(struct rte_eth_dev *dev)
nfp_net_stop(dev);
+ rte_intr_disable(&dev->pci_dev->intr_handle);
nn_cfg_writeb(hw, NFP_NET_CFG_LSC, 0xff);
/*
@@ -1115,6 +1119,114 @@ nfp_net_rx_queue_count(struct rte_eth_dev *dev,
uint16_t queue_idx)
return count;
}
+static void
+nfp_net_dev_link_status_print(struct rte_eth_dev *dev)
+{
+ struct rte_eth_link link;
+
+ memset(&link, 0, sizeof(link));
+ nfp_net_dev_atomic_read_link_status(dev, &link);
+ if (link.link_status)
+ RTE_LOG(INFO, PMD, "Port %d: Link Up - speed %u Mbps - %s\n",
+ (int)(dev->data->port_id), (unsigned)link.link_speed,
+ link.link_duplex == ETH_LINK_FULL_DUPLEX
+ ? "full-duplex" : "half-duplex");
+ else
+ RTE_LOG(INFO, PMD, " Port %d: Link Down\n",
+ (int)(dev->data->port_id));
+
+ RTE_LOG(INFO, PMD, "PCI Address: %04d:%02d:%02d:%d\n",
+ dev->pci_dev->addr.domain, dev->pci_dev->addr.bus,
+ dev->pci_dev->addr.devid, dev->pci_dev->addr.function);
+}
+
+/* Interrupt configuration and handling */
+
+/*
+ * nfp_net_irq_unmask - Unmask an interrupt
+ *
+ * If MSI-X auto-masking is enabled clear the mask bit, otherwise
+ * clear the ICR for the entry.
+ */
+static void
+nfp_net_irq_unmask(struct rte_eth_dev *dev)
+{
+ struct nfp_net_hw *hw;
+
+ hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+ if (hw->ctrl & NFP_NET_CFG_CTRL_MSIXAUTO) {
+ /* If MSI-X auto-masking is used, clear the entry */
+ rte_wmb();
+ rte_intr_enable(&dev->pci_dev->intr_handle);
+ } else {
+ /* Make sure all updates are written before un-masking */
+ rte_wmb();
+ nn_cfg_writeb(hw, NFP_NET_CFG_ICR(NFP_NET_IRQ_LSC_IDX),
+ NFP_NET_CFG_ICR_UNMASKED);
+ }
+}
+
+static void
+nfp_net_dev_interrupt_handler(__rte_unused struct rte_intr_handle *handle,
+ void *param)
+{
+ int64_t timeout;
+ struct rte_eth_link link;
+ struct rte_eth_dev *dev = (struct rte_eth_dev *)param;
+
+ PMD_DRV_LOG(DEBUG, "We got a LSC interrupt!!!\n");
+
+ /* get the link status */
+ memset(&link, 0, sizeof(link));
+ nfp_net_dev_atomic_read_link_status(dev, &link);
+
+ nfp_net_link_update(dev, 0);
+
+ /* likely to up */
+ if (!link.link_status) {
+ /* handle it 1 sec later, wait it being stable */
+ timeout = NFP_NET_LINK_UP_CHECK_TIMEOUT;
+ /* likely to down */
+ } else {
+ /* handle it 4 sec later, wait it being stable */
+ timeout = NFP_NET_LINK_DOWN_CHECK_TIMEOUT;
+ }
+
+ if (rte_eal_alarm_set(timeout * 1000,
+ nfp_net_dev_interrupt_delayed_handler,
+ (void *)dev) < 0) {
+ RTE_LOG(ERR, PMD, "Error setting alarm");
+ /* Unmasking */
+ nfp_net_irq_unmask(dev);
+ }
+}
+
+/*
+ * Interrupt handler which shall be registered for alarm callback for delayed
+ * handling specific interrupt to wait for the stable nic state. As the NIC
+ * interrupt state is not stable for nfp after link is just down, it needs
+ * to wait 4 seconds to get the stable status.
+ *
+ * @param handle Pointer to interrupt handle.
+ * @param paramThe address of parameter (struct rte_eth_dev *)
+ *
+ * @return void
+ */
+static void
+nfp_net_dev_interrupt_delayed_handler(void *param)
+{
+ struct rte_eth_dev *dev = (struct rte_eth_dev *)param;
+
+ nfp_net_link_update(dev, 0);
+ _rte_eth_dev_callback_process(dev, RTE_ETH_EVENT_INTR_LSC);
+
+ nfp_net_dev_link_status_print(dev);
+
+ /* Unmasking */
+ nfp_net_irq_unmask(dev);
+}
+
static int
nfp_net_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
{
@@ -2315,6 +2427,17 @@ nfp_net_init(struct rte_eth_dev *eth_dev)
[dpdk-dev] [PATCH v10 2/8] nfp: adding rx/tx functionality
Signed-off-by: Alejandro Lucero
Signed-off-by: Rolf Neugebauer
---
drivers/net/nfp/nfp_net.c | 993 +
1 file changed, 993 insertions(+)
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index b9240db..0d85fa4 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -74,8 +74,25 @@
static void nfp_net_close(struct rte_eth_dev *dev);
static int nfp_net_configure(struct rte_eth_dev *dev);
static int nfp_net_init(struct rte_eth_dev *eth_dev);
+static int nfp_net_rx_fill_freelist(struct nfp_net_rxq *rxq);
+static uint32_t nfp_net_rx_queue_count(struct rte_eth_dev *dev,
+ uint16_t queue_idx);
+static uint16_t nfp_net_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
+ uint16_t nb_pkts);
+static void nfp_net_rx_queue_release(void *rxq);
+static int nfp_net_rx_queue_setup(struct rte_eth_dev *dev, uint16_t queue_idx,
+ uint16_t nb_desc, unsigned int socket_id,
+ const struct rte_eth_rxconf *rx_conf,
+ struct rte_mempool *mp);
+static int nfp_net_tx_free_bufs(struct nfp_net_txq *txq);
+static void nfp_net_tx_queue_release(void *txq);
+static int nfp_net_tx_queue_setup(struct rte_eth_dev *dev, uint16_t queue_idx,
+ uint16_t nb_desc, unsigned int socket_id,
+ const struct rte_eth_txconf *tx_conf);
static int nfp_net_start(struct rte_eth_dev *dev);
static void nfp_net_stop(struct rte_eth_dev *dev);
+static uint16_t nfp_net_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
+ uint16_t nb_pkts);
/*
* The offset of the queue controller queues in the PCIe Target. These
@@ -186,6 +203,100 @@ nn_cfg_writeq(struct nfp_net_hw *hw, int off, uint64_t
val)
nn_writeq(rte_cpu_to_le_64(val), hw->ctrl_bar + off);
}
+/* Creating memzone for hardware rings. */
+static const struct rte_memzone *
+ring_dma_zone_reserve(struct rte_eth_dev *dev, const char *ring_name,
+ uint16_t queue_id, uint32_t ring_size, int socket_id)
+{
+ char z_name[RTE_MEMZONE_NAMESIZE];
+ const struct rte_memzone *mz;
+
+ snprintf(z_name, sizeof(z_name), "%s_%s_%d_%d",
+dev->driver->pci_drv.name,
+ring_name, dev->data->port_id, queue_id);
+
+ mz = rte_memzone_lookup(z_name);
+ if (mz)
+ return mz;
+
+ return rte_memzone_reserve_aligned(z_name, ring_size, socket_id, 0,
+ NFP_MEMZONE_ALIGN);
+}
+
+static void
+nfp_net_rx_queue_release_mbufs(struct nfp_net_rxq *rxq)
+{
+ unsigned i;
+
+ if (rxq->rxbufs == NULL)
+ return;
+
+ for (i = 0; i < rxq->rx_count; i++) {
+ if (rxq->rxbufs[i].mbuf) {
+ rte_pktmbuf_free_seg(rxq->rxbufs[i].mbuf);
+ rxq->rxbufs[i].mbuf = NULL;
+ }
+ }
+}
+
+static void
+nfp_net_rx_queue_release(void *rx_queue)
+{
+ struct nfp_net_rxq *rxq = rx_queue;
+
+ if (rxq) {
+ nfp_net_rx_queue_release_mbufs(rxq);
+ rte_free(rxq->rxbufs);
+ rte_free(rxq);
+ }
+}
+
+static void
+nfp_net_reset_rx_queue(struct nfp_net_rxq *rxq)
+{
+ nfp_net_rx_queue_release_mbufs(rxq);
+ rxq->wr_p = 0;
+ rxq->rd_p = 0;
+ rxq->nb_rx_hold = 0;
+}
+
+static void
+nfp_net_tx_queue_release_mbufs(struct nfp_net_txq *txq)
+{
+ unsigned i;
+
+ if (txq->txbufs == NULL)
+ return;
+
+ for (i = 0; i < txq->tx_count; i++) {
+ if (txq->txbufs[i].mbuf) {
+ rte_pktmbuf_free_seg(txq->txbufs[i].mbuf);
+ txq->txbufs[i].mbuf = NULL;
+ }
+ }
+}
+
+static void
+nfp_net_tx_queue_release(void *tx_queue)
+{
+ struct nfp_net_txq *txq = tx_queue;
+
+ if (txq) {
+ nfp_net_tx_queue_release_mbufs(txq);
+ rte_free(txq->txbufs);
+ rte_free(txq);
+ }
+}
+
+static void
+nfp_net_reset_tx_queue(struct nfp_net_txq *txq)
+{
+ nfp_net_tx_queue_release_mbufs(txq);
+ txq->wr_p = 0;
+ txq->rd_p = 0;
+ txq->tail = 0;
+}
+
static int
__nfp_net_reconfig(struct nfp_net_hw *hw, uint32_t update)
{
@@ -423,6 +534,18 @@ nfp_net_disable_queues(struct rte_eth_dev *dev)
hw->ctrl = new_ctrl;
}
+static int
+nfp_net_rx_freelist_setup(struct rte_eth_dev *dev)
+{
+ int i;
+
+ for (i = 0; i < dev->data->nb_rx_queues; i++) {
+ if (nfp_net_rx_fill_freelist(dev->data->rx_queues[i]) < 0)
+ return -1;
+ }
+ return 0;
+}
+
static void
nfp_net_params_setup(struct nfp_net_hw *hw)
{
@@ -451,6 +574,7 @@ nfp_net_start(struct rte_eth_dev *dev)
{
uint32_t new_ctrl, update = 0;
[dpdk-dev] [PATCH v10 6/8] nfp: adding extra functionality
Signed-off-by: Alejandro Lucero
Signed-off-by: Rolf Neugebauer
---
drivers/net/nfp/nfp_net.c | 191 +
1 file changed, 191 insertions(+)
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index 7c82e96..ff9a8d6 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -73,8 +73,13 @@
/* Prototypes */
static void nfp_net_close(struct rte_eth_dev *dev);
static int nfp_net_configure(struct rte_eth_dev *dev);
+static int nfp_net_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu);
+static void nfp_net_infos_get(struct rte_eth_dev *dev,
+ struct rte_eth_dev_info *dev_info);
static int nfp_net_init(struct rte_eth_dev *eth_dev);
static int nfp_net_link_update(struct rte_eth_dev *dev, int wait_to_complete);
+static void nfp_net_promisc_enable(struct rte_eth_dev *dev);
+static void nfp_net_promisc_disable(struct rte_eth_dev *dev);
static int nfp_net_rx_fill_freelist(struct nfp_net_rxq *rxq);
static uint32_t nfp_net_rx_queue_count(struct rte_eth_dev *dev,
uint16_t queue_idx);
@@ -734,6 +739,65 @@ nfp_net_close(struct rte_eth_dev *dev)
*/
}
+static void
+nfp_net_promisc_enable(struct rte_eth_dev *dev)
+{
+ uint32_t new_ctrl, update = 0;
+ struct nfp_net_hw *hw;
+
+ PMD_DRV_LOG(DEBUG, "Promiscuous mode enable\n");
+
+ hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+ if (!(hw->cap & NFP_NET_CFG_CTRL_PROMISC)) {
+ PMD_INIT_LOG(INFO, "Promiscuous mode not supported\n");
+ return;
+ }
+
+ if (hw->ctrl & NFP_NET_CFG_CTRL_PROMISC) {
+ PMD_DRV_LOG(INFO, "Promiscuous mode already enabled\n");
+ return;
+ }
+
+ new_ctrl = hw->ctrl | NFP_NET_CFG_CTRL_PROMISC;
+ update = NFP_NET_CFG_UPDATE_GEN;
+
+ /*
+* DPDK sets promiscuous mode on just after this call assuming
+* it can not fail ...
+*/
+ if (nfp_net_reconfig(hw, new_ctrl, update) < 0)
+ return;
+
+ hw->ctrl = new_ctrl;
+}
+
+static void
+nfp_net_promisc_disable(struct rte_eth_dev *dev)
+{
+ uint32_t new_ctrl, update = 0;
+ struct nfp_net_hw *hw;
+
+ hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+ if ((hw->ctrl & NFP_NET_CFG_CTRL_PROMISC) == 0) {
+ PMD_DRV_LOG(INFO, "Promiscuous mode already disabled\n");
+ return;
+ }
+
+ new_ctrl = hw->ctrl & ~NFP_NET_CFG_CTRL_PROMISC;
+ update = NFP_NET_CFG_UPDATE_GEN;
+
+ /*
+* DPDK sets promiscuous mode off just before this call
+* assuming it can not fail ...
+*/
+ if (nfp_net_reconfig(hw, new_ctrl, update) < 0)
+ return;
+
+ hw->ctrl = new_ctrl;
+}
+
/*
* return 0 means link status changed, -1 means not changed
*
@@ -948,6 +1012,65 @@ nfp_net_stats_reset(struct rte_eth_dev *dev)
nn_cfg_readq(hw, NFP_NET_CFG_STATS_RX_DISCARDS);
}
+static void
+nfp_net_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
+{
+ struct nfp_net_hw *hw;
+
+ hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+
+ dev_info->driver_name = dev->driver->pci_drv.name;
+ dev_info->max_rx_queues = (uint16_t)hw->max_rx_queues;
+ dev_info->max_tx_queues = (uint16_t)hw->max_tx_queues;
+ dev_info->min_rx_bufsize = ETHER_MIN_MTU;
+ dev_info->max_rx_pktlen = hw->mtu;
+ /* Next should change when PF support is implemented */
+ dev_info->max_mac_addrs = 1;
+
+ if (hw->cap & NFP_NET_CFG_CTRL_RXVLAN)
+ dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP;
+
+ if (hw->cap & NFP_NET_CFG_CTRL_RXCSUM)
+ dev_info->rx_offload_capa |= DEV_RX_OFFLOAD_IPV4_CKSUM |
+DEV_RX_OFFLOAD_UDP_CKSUM |
+DEV_RX_OFFLOAD_TCP_CKSUM;
+
+ if (hw->cap & NFP_NET_CFG_CTRL_TXVLAN)
+ dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT;
+
+ if (hw->cap & NFP_NET_CFG_CTRL_TXCSUM)
+ dev_info->tx_offload_capa |= DEV_TX_OFFLOAD_IPV4_CKSUM |
+DEV_RX_OFFLOAD_UDP_CKSUM |
+DEV_RX_OFFLOAD_TCP_CKSUM;
+
+ dev_info->default_rxconf = (struct rte_eth_rxconf) {
+ .rx_thresh = {
+ .pthresh = DEFAULT_RX_PTHRESH,
+ .hthresh = DEFAULT_RX_HTHRESH,
+ .wthresh = DEFAULT_RX_WTHRESH,
+ },
+ .rx_free_thresh = DEFAULT_RX_FREE_THRESH,
+ .rx_drop_en = 0,
+ };
+
+ dev_info->default_txconf = (struct rte_eth_txconf) {
+ .tx_thresh = {
+ .pthresh = DEFAULT_TX_PTHRESH,
+ .hthresh = DEFAULT_TX_HTHRESH,
+
[dpdk-dev] [PATCH v10 8/8] nfp: adding nic guide
Signed-off-by: Alejandro Lucero Signed-off-by: Rolf Neugebauer --- MAINTAINERS |1 + doc/guides/nics/index.rst |1 + doc/guides/nics/nfp.rst | 265 + 3 files changed, 267 insertions(+) create mode 100644 doc/guides/nics/nfp.rst diff --git a/MAINTAINERS b/MAINTAINERS index a23de04..b5db75f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -338,6 +338,7 @@ F: drivers/crypto/qat/ Netronome nfp M: Alejandro Lucero F: drivers/net/nfp/ +F: doc/guides/nics/nfp.rst Packet processing - diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst index 0a0b724..7bf2938 100644 --- a/doc/guides/nics/index.rst +++ b/doc/guides/nics/index.rst @@ -46,6 +46,7 @@ Network Interface Controller Drivers intel_vf mlx4 mlx5 +nfp szedata2 virtio vmxnet3 diff --git a/doc/guides/nics/nfp.rst b/doc/guides/nics/nfp.rst new file mode 100644 index 000..55ba64d --- /dev/null +++ b/doc/guides/nics/nfp.rst @@ -0,0 +1,265 @@ +.. BSD LICENSE +Copyright(c) 2015 Netronome Systems, Inc. All rights reserved. +All rights reserved. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions +are met: + +* Redistributions of source code must retain the above copyright +notice, this list of conditions and the following disclaimer. +* Redistributions in binary form must reproduce the above copyright +notice, this list of conditions and the following disclaimer in +the documentation and/or other materials provided with the +distribution. +* Neither the name of Intel Corporation nor the names of its +contributors may be used to endorse or promote products derived +from this software without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT +OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE +OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + +NFP poll mode driver library + + +Netronome's sixth generation of flow processors pack 216 programmable +cores and over 100 hardware accelerators that uniquely combine packet, +flow, security and content processing in a single device that scales +up to 400 Gbps. + +This document explains how to use DPDK with the Netronome Poll Mode +Driver (PMD) supporting Netronome's Network Flow Processor 6xxx +(NFP-6xxx). + +Currently the driver supports virtual functions (VFs) only. + +Dependencies + + +Before using the Netronome's DPDK PMD some NFP-6xxx configuration, +which is not related to DPDK, is required. The system requires +installation of **Netronome's BSP (Board Support Package)** which includes +Linux drivers, programs and libraries. + +If you have a NFP-6xxx device you should already have the code and +documentation for doing this configuration. Contact +**support at netronome.com** to obtain the latest available firmware. + +The NFP Linux kernel drivers (including the required PF driver for the +NFP) are available on Github at +**https://github.com/Netronome/nfp-drv-kmods** along with build +instructions. + +DPDK runs in userspace and PMDs uses the Linux kernel UIO interface to +allow access to physical devices from userspace. The NFP PMD requires +a separate UIO driver, **nfp_uio**, to perform correct +initialization. This driver is part of Netronome?s BSP and it is +equivalent to Intel's igb_uio driver. + +Building the software +- + +Netronome's PMD code is provided in the **drivers/net/nfp** directory. +Because Netronome?s BSP dependencies the driver is disabled by default +in DPDK build using **common_linuxapp configuration** file. Enabling the +driver or if you use another configuration file and want to have NFP +support, this variable is needed: + +- **CONFIG_RTE_LIBRTE_NFP_PMD=y** + +Once DPDK is built all the DPDK apps and examples include support for +the NFP PMD. + + +System configuration + + +Using the NFP PMD is not different to using other PMDs. Usual steps are: + +#. **Configure hugepages:** All major Linux distributions have the hugepages + functionality enabled by default. By default this allows the system uses for + working with transparent hugepages. But in this c
[dpdk-dev] [PATCH v10 1/8] nfp: basic initialization
Signed-off-by: Alejandro Lucero Signed-off-by: Rolf Neugebauer --- MAINTAINERS |3 + config/common_linuxapp |6 + doc/guides/rel_notes/release_2_2.rst|3 + drivers/net/Makefile|1 + drivers/net/nfp/Makefile| 56 +++ drivers/net/nfp/nfp_net.c | 699 +++ drivers/net/nfp/nfp_net_ctrl.h | 324 ++ drivers/net/nfp/nfp_net_logs.h | 75 drivers/net/nfp/nfp_net_pmd.h | 453 drivers/net/nfp/rte_pmd_nfp_version.map |3 + mk/rte.app.mk |1 + 11 files changed, 1624 insertions(+) create mode 100644 drivers/net/nfp/Makefile create mode 100644 drivers/net/nfp/nfp_net.c create mode 100644 drivers/net/nfp/nfp_net_ctrl.h create mode 100644 drivers/net/nfp/nfp_net_logs.h create mode 100644 drivers/net/nfp/nfp_net_pmd.h create mode 100644 drivers/net/nfp/rte_pmd_nfp_version.map diff --git a/MAINTAINERS b/MAINTAINERS index 4478862..a23de04 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -335,6 +335,9 @@ F: drivers/crypto/aesni_mb/ Intel QuickAssist F: drivers/crypto/qat/ +Netronome nfp +M: Alejandro Lucero +F: drivers/net/nfp/ Packet processing - diff --git a/config/common_linuxapp b/config/common_linuxapp index 2866986..82f68c7 100644 --- a/config/common_linuxapp +++ b/config/common_linuxapp @@ -279,6 +279,12 @@ CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_TX_FREE=n CONFIG_RTE_LIBRTE_VMXNET3_DEBUG_DRIVER=n # +# Compile burst-oriented Netronome NFP PMD driver +# +CONFIG_RTE_LIBRTE_NFP_PMD=n +CONFIG_RTE_LIBRTE_NFP_DEBUG=n + +# # Compile example software rings based PMD # CONFIG_RTE_LIBRTE_PMD_RING=y diff --git a/doc/guides/rel_notes/release_2_2.rst b/doc/guides/rel_notes/release_2_2.rst index 511d7a0..0a7c217 100644 --- a/doc/guides/rel_notes/release_2_2.rst +++ b/doc/guides/rel_notes/release_2_2.rst @@ -230,6 +230,9 @@ Libraries hardware transactional memory support, thread scaling did not work, due to the global ring that is shared by all cores. +* **nfp: adding new PMD for Netronome nfp-6xxx card.** + + Support for using Netronome nfp-6xxx with PCI VFs. Examples diff --git a/drivers/net/Makefile b/drivers/net/Makefile index cddcd57..6e4497e 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -43,6 +43,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += ixgbe DIRS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += mlx4 DIRS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5 DIRS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD) += mpipe +DIRS-$(CONFIG_RTE_LIBRTE_NFP_PMD) += nfp DIRS-$(CONFIG_RTE_LIBRTE_PMD_NULL) += null DIRS-$(CONFIG_RTE_LIBRTE_PMD_PCAP) += pcap DIRS-$(CONFIG_RTE_LIBRTE_PMD_RING) += ring diff --git a/drivers/net/nfp/Makefile b/drivers/net/nfp/Makefile new file mode 100644 index 000..ef7a13d --- /dev/null +++ b/drivers/net/nfp/Makefile @@ -0,0 +1,56 @@ +# BSD LICENSE +# +# Copyright(c) 2010-2014 Intel Corporation. All rights reserved. +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted provided that the following conditions +# are met: +# +# * Redistributions of source code must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# * Redistributions in binary form must reproduce the above copyright +# notice, this list of conditions and the following disclaimer in +# the documentation and/or other materials provided with the +# distribution. +# * Neither the name of Intel Corporation nor the names of its +# contributors may be used to endorse or promote products derived +# from this software without specific prior written permission. +# +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT +# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE +# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + +include $(RTE_SDK)/mk/rte.vars.mk + +# +# library name +# +LIB = librte_pmd_nfp.a + +CFLAGS += -O3 +CFLAGS += $(WERROR_FLAGS) + +EXPORT_MAP := rte_pmd_nfp_version.map + +LIBABIVER := 1 + +# +# all source are stored in SRCS-y +# +SRCS-$(CONFIG_RTE_LIBRTE_NFP_PMD) += nfp_net.c + +# this lib depends upon: +DEPDIRS-$(CONFIG_RTE_LIBRTE_NFP_PMD) += lib/librte_
[dpdk-dev] [PATCH v3 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm
On Mon, Nov 30, 2015 at 03:52:31PM +0530, Jerin Jacob wrote:
> On Mon, Nov 30, 2015 at 12:03:21PM -0500, Jianbo Liu wrote:
> > On Mon, Nov 30, 2015 at 11:17:52AM +0530, Jerin Jacob wrote:
> > > On Sun, Nov 29, 2015 at 06:48:29PM -0500, Jianbo Liu wrote:
> > > > On Fri, Nov 27, 2015 at 07:04:28PM +0530, Jerin Jacob wrote:
> > > > > Commit 42ec27a0178a causes compiling error on arm, as RTE_SCHED_VECTOR
> > > > > does support only SSE intrinsic, so disable it till we have neon
> > > > > support.
> > > > >
> > > > > Fixes: 42ec27a0178a ("sched: enable SSE optimizations in config")
> > > > >
> > > > > Signed-off-by: Jerin Jacob
> > > > > ---
> > > > > config/common_arm64 | 1 +
> > > > > config/defconfig_arm-armv7a-linuxapp-gcc | 1 +
> > > > > 2 files changed, 2 insertions(+)
> > > > >
> > > > > diff --git a/config/common_arm64 b/config/common_arm64
> > > > > index 5e5e303..d6a9cb9 100644
> > > > > --- a/config/common_arm64
> > > > > +++ b/config/common_arm64
> > > > > @@ -46,3 +46,4 @@ CONFIG_RTE_LIBRTE_I40E_PMD=n
> > > > > CONFIG_RTE_LIBRTE_LPM=n
> > > > > CONFIG_RTE_LIBRTE_TABLE=n
> > > > > CONFIG_RTE_LIBRTE_PIPELINE=n
> > > > > +CONFIG_RTE_SCHED_VECTOR=n
> > > > > diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc
> > > > > b/config/defconfig_arm-armv7a-linuxapp-gcc
> > > > > index 82143af..9924ff9 100644
> > > > > --- a/config/defconfig_arm-armv7a-linuxapp-gcc
> > > > > +++ b/config/defconfig_arm-armv7a-linuxapp-gcc
> > > > > @@ -57,6 +57,7 @@ CONFIG_RTE_LIBRTE_ACL=n
> > > > > CONFIG_RTE_LIBRTE_LPM=n
> > > > > CONFIG_RTE_LIBRTE_TABLE=n
> > > > > CONFIG_RTE_LIBRTE_PIPELINE=n
> > > > > +CONFIG_RTE_SCHED_VECTOR=n
> > > > >
> > > > > # cannot use those on ARM
> > > > > CONFIG_RTE_KNI_KMOD=n
> > > > > --
> > > > > 2.1.0
> > > > >
> > > >
> > > > Hi Jerin,
> > >
> > > Hi Jianbo, Thanks for the review.
> > > Looking forward to seeing contributions to DPDK-ARM.
> > > We definitely need more hands to make best DPDK-ARM port.
> > >
> > > > In this way, we still have to modify two files each time a new feature
> > > > is added but not verified on ARM architectures.
> > > > Since disabling those drivers and libs are common for both armv7 and
> > > > armv8, can you put them in one config file, for example: common_arm?
> > >
> > > I initially thought of making it a single common_arm file, Then
> > > later I realized that it may not be worth as,
> > >
> > > 1) If a new feature added to DPDK which has the dependency on SSE then
> > > implementer has to disable on "n" platforms(tile, powerpc..).By unifying
> > > single arm config will make it "n-1" so it's like "n" vs "n-1" not "n"
> > > vs "2n"
> >
> > I'm talking about your patch, which is for ARM platform only. And the
> > two files we need to modify are armv7 and armv8 configs.
> > If you want to include other platforms, your patch is still incomplete :)
> >
>
> That was the reply for the concern you have raised for the new feature.
> Not specific to my patch. My patch is complete, as I have
> checked other platforms before sending the patch
> they have already disabled the sched library :-)
>
>
> > >
> > > 2) AFAIK, PCI NIC PMD's are not yet supported in ARMv7 platform yet
> > > unlike ARMv8.
> > > Till we have PCI NIC PMD support, armv7 config needs to be updated
> > > for each and every new PMD inclusion.
> > >
> > > 3) neon capabilities are bit different in ARMv7 and ARMv8.
> > > For instance, "vqtbl1q_u8" neon intrinsics is not defined in ARMv7 which
> > > used
> > > in implementing ACL-NEON. i.e Need additional efforts to extend
> > > the armv8 neon code to armv7(or vice versa).So it's better to
> > > have fine control on the config file to enable selective features
> > >
> >
> > The differences between ARMv7 and ARMv8 can't justify we only add new
> > config for ARMv8. And this file is trying to disable drivers and libs
> > which is not supported on ARM platforms for now.
> >
>
> I thought difference and point 3 should justify the need for different
> config. No?
>
>
> > > 3) anyway we may need common_armv8 file to address the "IMPLEMENTATION
> > > DEFINED" parts of the armv8 specific in future, like frequency at
> > > cntvct_el0
> > > runs ? optional features like armv8 crypto instruction support or not?
> > > It's armv8 v1 or v2 ? atomic instruction support for not? its a long
> > > list
> > >
> >
> > I think these "IMPLEMENTATION DEFINED" features should be configured
> > in the different platform (machine) config files. Can this
> > common_arm64 solve your concern?
>
> Yes, "IMPLEMENTATION DEFINED" features of armv8(default behavior in
> common_arm64). I think it makes sense not mix with armv7.
>
> >
> > > 4)I would like to see ARM configs as different config like i686, X86_64
> > > in DPDK
> > >
> >
> > Basically, we need to use the default common_linux/bsd to enable the
> > new-added features in DPDK.
> >
> > >
> > > > It is not like common_arm64, which is solely for armv8 platfor
[dpdk-dev] [PATCH] reserve 'make install' for future use
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Friday, November 27, 2015 5:33 PM > To: Panu Matilainen ; Richardson, Bruce > > Cc: dev at dpdk.org; olivier.matz at 6wind.com > Subject: Re: [dpdk-dev] [PATCH] reserve 'make install' for future use > > 2015-11-25 10:48, Panu Matilainen: > > On 11/24/2015 06:54 PM, Bruce Richardson wrote: > > > On Fri, Nov 06, 2015 at 02:04:54PM +0100, Thomas Monjalon wrote: > > >> 2015-11-06 12:57, Bruce Richardson: > > >>> So, any thoughts or comments on this? There has been lots of > > >>> discussion in this general area but nothing yet going into the > release to try and improve the situation. > > >>> > > >>> Are we just going to kick the problem down the road to the 2.3 > release? > > >> > > >> I plan to check these patches in the coming days for an integration > in 2.2. > > >> > > > Anything further on this? > > > Any thoughts from anyone else about this whole area of a saner > > > build/install system for DPDK and the various patches floating around. > > > > Well, it seems we wont have a sane "make install" in 2.2 yet, but this > > is at least a step in the right direction so +1 from me. > > Why is it a step in the right direction? > > We just need to install the files in a different hierarchy and adapt the > makefiles to be able to compile an application while keeping the RTE_SDK > variable to specify the root directory (previously built thanks to > DESTDIR). > As the hierarchy could be tuned, we need more variables, e.g.: > DPDK_INC_DIR (default = RTE_SDK/include/dpdk) > DPDK_LIB_DIR (default = RTE_SDK/lib) > > While doing it, we can have a specific handling of T= to keep > compatibility with the current (old) syntax. > > What have I missed? > I'm not sure our existing "make install" is suitable for use for this, without having it heavily overloaded. The existing T= behavior has support for wildcards and compiling multiple instances at the same time - something that won't work with a scheme to actually install DPDK throughout the filesystem hierarchy. Having it sometimes behave as now, and sometimes behave as a standard make install is a bad idea IMHO, as it confuses things. Having lots of extra environment variables is also not a great idea, to my mind. My opinion is that we should rename our existing "make install" to something more suitable - my patch suggestion was "make sdk" but it could be "make target" or something else if people prefer. Once that is done, we can then look to implement a proper "make install" command that works in a standard way, perhaps alongside a configure script of some description. For an easy enough solution, I would look to apply this patch to create "make sdk" and also http://dpdk.org/dev/patchwork/patch/8076/ to have a "make install" command that works in the build dir. That way: * you can have existing behavior using "make sdk T=" * you can have standard(ish) configure/make/make install behavior using: make config T= cd build make make install and the "make config" step can subsequently be wrapped in a configure script to eliminate the need to know what the best target to use is, etc. /Bruce
[dpdk-dev] [PATCH] reserve 'make install' for future use
2015-11-30 11:08, Richardson, Bruce: > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > Why is it a step in the right direction? > > > > We just need to install the files in a different hierarchy and adapt the > > makefiles to be able to compile an application while keeping the RTE_SDK > > variable to specify the root directory (previously built thanks to > > DESTDIR). > > As the hierarchy could be tuned, we need more variables, e.g.: > > DPDK_INC_DIR (default = RTE_SDK/include/dpdk) > > DPDK_LIB_DIR (default = RTE_SDK/lib) > > > > While doing it, we can have a specific handling of T= to keep > > compatibility with the current (old) syntax. > > > > What have I missed? > > > > > I'm not sure our existing "make install" is suitable for use for this, > without having it heavily overloaded. The existing T= behavior has support > for wildcards and compiling multiple instances at the same time - something > that won't work with a scheme to actually install DPDK throughout the > filesystem hierarchy. Having it sometimes behave as now, and sometimes behave > as a standard make install is a bad idea IMHO, as it confuses things. Having > lots of extra environment variables is also not a great idea, to my mind. Yes I agree. I forgot to mention it, but in my idea, we can drop the support for multiple targets. So the T= compatibility would be only a shortcut to do "make config" and name the build directory based on the template name. About the environment variables: An application requires CFLAGS and LDFLAGS (at least). The standard way to provide them is pkgconfig (not implemented yet). For applications using the DPDK makefiles, the only input is RTE_SDK. When allowing more tuning in paths, we need more variables when using the DPDK makefiles to build an application. > My opinion is that we should rename our existing "make install" to something > more suitable - my patch suggestion was "make sdk" but it could be "make > target" or something else if people prefer. Once that is done, we can then > look to implement a proper "make install" command that works in a standard > way, perhaps alongside a configure script of some description. I think we don't need to rename or move some code. Just drop and replace some of them. The configure script is a great idea but it is a totally different idea. I do not think that installation and configuration should be related. Please let's consider "make install" first. > For an easy enough solution, I would look to apply this patch to create "make > sdk" and also http://dpdk.org/dev/patchwork/patch/8076/ to have a "make > install" command that works in the build dir. That way: > * you can have existing behavior using "make sdk T=" > * you can have standard(ish) configure/make/make install behavior using: > make config T= > cd build > make > make install > and the "make config" step can subsequently be wrapped in a configure > script to eliminate the need to know what the best target to use is, etc. As Panu commented, I do not think it is a good idea to have different behaviours inside and outside of the build directory. I would even say that this embedded makefile is only confusing and should be dropped. We need to have *one* right building methods, not to bring more confusion.
[dpdk-dev] [PATCH] reserve 'make install' for future use
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Monday, November 30, 2015 11:27 AM > To: Richardson, Bruce > Cc: Panu Matilainen ; dev at dpdk.org; > olivier.matz at 6wind.com > Subject: Re: [dpdk-dev] [PATCH] reserve 'make install' for future use > > 2015-11-30 11:08, Richardson, Bruce: > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > Why is it a step in the right direction? > > > > > > We just need to install the files in a different hierarchy and adapt > > > the makefiles to be able to compile an application while keeping the > > > RTE_SDK variable to specify the root directory (previously built > > > thanks to DESTDIR). > > > As the hierarchy could be tuned, we need more variables, e.g.: > > > DPDK_INC_DIR (default = RTE_SDK/include/dpdk) > > > DPDK_LIB_DIR (default = RTE_SDK/lib) > > > > > > While doing it, we can have a specific handling of T= to keep > > > compatibility with the current (old) syntax. > > > > > > What have I missed? > > > > > > > > > I'm not sure our existing "make install" is suitable for use for this, > without having it heavily overloaded. The existing T= behavior has support > for wildcards and compiling multiple instances at the same time - > something that won't work with a scheme to actually install DPDK > throughout the filesystem hierarchy. Having it sometimes behave as now, > and sometimes behave as a standard make install is a bad idea IMHO, as it > confuses things. Having lots of extra environment variables is also not a > great idea, to my mind. > > Yes I agree. > I forgot to mention it, but in my idea, we can drop the support for > multiple targets. So the T= compatibility would be only a shortcut to do > "make config" and name the build directory based on the template name. > > About the environment variables: > An application requires CFLAGS and LDFLAGS (at least). The standard way to > provide them is pkgconfig (not implemented yet). > For applications using the DPDK makefiles, the only input is RTE_SDK. > When allowing more tuning in paths, we need more variables when using the > DPDK makefiles to build an application. > > > My opinion is that we should rename our existing "make install" to > something more suitable - my patch suggestion was "make sdk" but it could > be "make target" or something else if people prefer. Once that is done, we > can then look to implement a proper "make install" command that works in a > standard way, perhaps alongside a configure script of some description. > > I think we don't need to rename or move some code. > Just drop and replace some of them. > > The configure script is a great idea but it is a totally different idea. > I do not think that installation and configuration should be related. > Please let's consider "make install" first. > > > For an easy enough solution, I would look to apply this patch to create > "make sdk" and also http://dpdk.org/dev/patchwork/patch/8076/ to have a > "make install" command that works in the build dir. That way: > > * you can have existing behavior using "make sdk T=" > > * you can have standard(ish) configure/make/make install behavior using: > > make config T= > > cd build > > make > > make install > > and the "make config" step can subsequently be wrapped in a configure > script to eliminate the need to know what the best target to use is, etc. > > As Panu commented, I do not think it is a good idea to have different > behaviours inside and outside of the build directory. > I would even say that this embedded makefile is only confusing and should > be dropped. > We need to have *one* right building methods, not to bring more confusion. I disagree. I don't think we can have *one* right building method, because to do so means completely throwing away our existing methods of building DPDK and using sample applications. That general method, using RTE_SDK and RTE_TARGET needs to be supported for some time for those projects already familiar with it and using it. As well as this, we also need a sane way of building DPDK inside the "build" directory, and having a "make install" target that installs the libraries and headers inside /usr/local (or whatever was specified as $prefix). With regards to different behavior, since different targets are provided, I don't see it as a problem. In the root directory, "make config" and "make sdk" are provided for backward compatibility. Inside the build directory you have your standard "make" and "make install" commands. Since the command set is very limited, it's easy enough to print a suitable error when the wrong command is used in the wrong place. Yes, I would like the ideal state where we have one set of build commands that are run from just one location. However, I don't think we can get to that objective without going through a transition phase where we support both old and new options. /Bruce
[dpdk-dev] [PATCH] reserve 'make install' for future use
On Mon, Nov 30, 2015 at 11:41:32AM +, Richardson, Bruce wrote: > > > > -Original Message- > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > Sent: Monday, November 30, 2015 11:27 AM > > To: Richardson, Bruce > > Cc: Panu Matilainen ; dev at dpdk.org; > > olivier.matz at 6wind.com > > Subject: Re: [dpdk-dev] [PATCH] reserve 'make install' for future use > > > > 2015-11-30 11:08, Richardson, Bruce: > > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > > Why is it a step in the right direction? > > > > > > > > We just need to install the files in a different hierarchy and adapt > > > > the makefiles to be able to compile an application while keeping the > > > > RTE_SDK variable to specify the root directory (previously built > > > > thanks to DESTDIR). > > > > As the hierarchy could be tuned, we need more variables, e.g.: > > > > DPDK_INC_DIR (default = RTE_SDK/include/dpdk) > > > > DPDK_LIB_DIR (default = RTE_SDK/lib) > > > > > > > > While doing it, we can have a specific handling of T= to keep > > > > compatibility with the current (old) syntax. > > > > > > > > What have I missed? > > > > > > > > > > > > > I'm not sure our existing "make install" is suitable for use for this, > > without having it heavily overloaded. The existing T= behavior has support > > for wildcards and compiling multiple instances at the same time - > > something that won't work with a scheme to actually install DPDK > > throughout the filesystem hierarchy. Having it sometimes behave as now, > > and sometimes behave as a standard make install is a bad idea IMHO, as it > > confuses things. Having lots of extra environment variables is also not a > > great idea, to my mind. > > > > Yes I agree. > > I forgot to mention it, but in my idea, we can drop the support for > > multiple targets. So the T= compatibility would be only a shortcut to do > > "make config" and name the build directory based on the template name. > > > > About the environment variables: > > An application requires CFLAGS and LDFLAGS (at least). The standard way to > > provide them is pkgconfig (not implemented yet). > > For applications using the DPDK makefiles, the only input is RTE_SDK. > > When allowing more tuning in paths, we need more variables when using the > > DPDK makefiles to build an application. > > > > > My opinion is that we should rename our existing "make install" to > > something more suitable - my patch suggestion was "make sdk" but it could > > be "make target" or something else if people prefer. Once that is done, we > > can then look to implement a proper "make install" command that works in a > > standard way, perhaps alongside a configure script of some description. > > > > I think we don't need to rename or move some code. > > Just drop and replace some of them. > > > > The configure script is a great idea but it is a totally different idea. > > I do not think that installation and configuration should be related. > > Please let's consider "make install" first. > > > > > For an easy enough solution, I would look to apply this patch to create > > "make sdk" and also http://dpdk.org/dev/patchwork/patch/8076/ to have a > > "make install" command that works in the build dir. That way: > > > * you can have existing behavior using "make sdk T=" > > > * you can have standard(ish) configure/make/make install behavior using: > > > make config T= > > > cd build > > > make > > > make install > > > and the "make config" step can subsequently be wrapped in a configure > > script to eliminate the need to know what the best target to use is, etc. > > > > As Panu commented, I do not think it is a good idea to have different > > behaviours inside and outside of the build directory. > > I would even say that this embedded makefile is only confusing and should > > be dropped. > > We need to have *one* right building methods, not to bring more confusion. > > I disagree. I don't think we can have *one* right building method, because to > do so means completely throwing away our existing methods of building DPDK > and using sample applications. That general method, using RTE_SDK and > RTE_TARGET > needs to be supported for some time for those projects already familiar with > it > and using it. > As well as this, we also need a sane way of building DPDK inside the "build" > directory, and having a "make install" target that installs the libraries > and headers inside /usr/local (or whatever was specified as $prefix). > > With regards to different behavior, since different targets are provided, I > don't see it as a problem. In the root directory, "make config" and "make sdk" > are provided for backward compatibility. Inside the build directory you have > your standard "make" and "make install" commands. Since the command set is > very limited, it's easy enough to print a suitable error when the wrong > command is used in the wrong place. By way of follow-up to my own email, I'd
[dpdk-dev] [PATCH] reserve 'make install' for future use
On 11/27/2015 07:33 PM, Thomas Monjalon wrote: > 2015-11-25 10:48, Panu Matilainen: >> On 11/24/2015 06:54 PM, Bruce Richardson wrote: >>> On Fri, Nov 06, 2015 at 02:04:54PM +0100, Thomas Monjalon wrote: 2015-11-06 12:57, Bruce Richardson: > So, any thoughts or comments on this? There has been lots of discussion > in this > general area but nothing yet going into the release to try and improve > the situation. > > Are we just going to kick the problem down the road to the 2.3 release? I plan to check these patches in the coming days for an integration in 2.2. >>> Anything further on this? >>> Any thoughts from anyone else about this whole area of a saner build/install >>> system for DPDK and the various patches floating around. >> >> Well, it seems we wont have a sane "make install" in 2.2 yet, but this >> is at least a step in the right direction so +1 from me. > > Why is it a step in the right direction? Right direction as in, everybody seems to agree we want "make install" ultimately do the right thing. If we can't have it in 2.2 yet then a preparatory step is better than not having it. > We just need to install the files in a different hierarchy and adapt > the makefiles to be able to compile an application while keeping the > RTE_SDK variable to specify the root directory (previously built thanks > to DESTDIR). > As the hierarchy could be tuned, we need more variables, e.g.: > DPDK_INC_DIR (default = RTE_SDK/include/dpdk) > DPDK_LIB_DIR (default = RTE_SDK/lib) > > While doing it, we can have a specific handling of T= to keep compatibility > with the current (old) syntax. > > What have I missed? Perhaps its me who has missed the fact that 2.2 is still open for these kind of things. If it were up to me, I think I'd just apply Marios latest patch series (perhaps condence it somewhat) to get it over with, fine-tune later if/as necessary. This is veering to the side of bikeshedding real fast. BTW, one noteworthy point is that in all of these related threads, nobody absolutely nobody has spoken up for the current behavior of "make install". Which makes me wonder if anybody is actually using it, and whether all this is just worrying for nothing. - Panu -
[dpdk-dev] Query on Filtering Support in DPDK
Hi, We are working towards adding h/w based filtering support in cxgbe PMD. Chelsio T5 supports carrying out filtering in hardware which supports 3 actions to carry out on a packet which hit a filter viz. 1. Action Pass - Packets hitting a filter rule can be directed to a particular RXQ. 2. Action Drop - Packets hitting a filter rule are dropped in h/w. 3. Action Switch - Packets hitting a filter rule can be switched in h/w from one port to another, without involvement of host. Also, the action Switch also supports rewrite of src-mac/dst-mac headers as well as rewrite of vlan headers. It also supports rewrite of IP headers and thereby, supports NAT (Network Address Translation) in h/w. Also, each filter rule can optionally support specifying a mask value i.e. it's possible to create a filter rule for an entire subnet of IP addresses or a range of tcp/udp ports, etc. We went through the existing filtering support (ethertype_filter, syn_filter, ntuple_filter, flow_director) and have some questions on how to accommodate the various h/w filtering features supported by Chelsio T5 by extending DPDK filtering support. Some of the features that we would like to accommodate in DPDK filtering are: 1. Add a new action 'switch' that will: * Allow re-direction to different ports in hardware. Also, for such a rule, additionally support below: * Allow source mac/destination mac and vlan header re-writing to be done by the hardware. * Allow re-write of TCP/IP headers to perform NAT in hardware. 2. Add ability to mask individual fields at a particular layer for each filter in flow_director. For example, mask all ip packets coming from a particular subnet mask and particular range of l4 ports for each filter rule. We would like to get some suggestions on how to proceed with adding the above features. Thanks, Rahul
[dpdk-dev] [PATCH v3 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm
On Mon, 30 Nov 2015 13:55:45 -0500
Jianbo Liu wrote:
> On Mon, Nov 30, 2015 at 03:52:31PM +0530, Jerin Jacob wrote:
> > On Mon, Nov 30, 2015 at 12:03:21PM -0500, Jianbo Liu wrote:
> > > On Mon, Nov 30, 2015 at 11:17:52AM +0530, Jerin Jacob wrote:
> > > > On Sun, Nov 29, 2015 at 06:48:29PM -0500, Jianbo Liu wrote:
> > > > > On Fri, Nov 27, 2015 at 07:04:28PM +0530, Jerin Jacob wrote:
> > > > > > Commit 42ec27a0178a causes compiling error on arm, as
> > > > > > RTE_SCHED_VECTOR
> > > > > > does support only SSE intrinsic, so disable it till we have neon
> > > > > > support.
> > > > > >
> > > > > > Fixes: 42ec27a0178a ("sched: enable SSE optimizations in config")
> > > > > >
> > > > > > Signed-off-by: Jerin Jacob
> > > > > > ---
> > > > > > config/common_arm64 | 1 +
> > > > > > config/defconfig_arm-armv7a-linuxapp-gcc | 1 +
> > > > > > 2 files changed, 2 insertions(+)
> > > > > >
> > > > > > diff --git a/config/common_arm64 b/config/common_arm64
> > > > > > index 5e5e303..d6a9cb9 100644
> > > > > > --- a/config/common_arm64
> > > > > > +++ b/config/common_arm64
> > > > > > @@ -46,3 +46,4 @@ CONFIG_RTE_LIBRTE_I40E_PMD=n
> > > > > > CONFIG_RTE_LIBRTE_LPM=n
> > > > > > CONFIG_RTE_LIBRTE_TABLE=n
> > > > > > CONFIG_RTE_LIBRTE_PIPELINE=n
> > > > > > +CONFIG_RTE_SCHED_VECTOR=n
> > > > > > diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc
> > > > > > b/config/defconfig_arm-armv7a-linuxapp-gcc
> > > > > > index 82143af..9924ff9 100644
> > > > > > --- a/config/defconfig_arm-armv7a-linuxapp-gcc
> > > > > > +++ b/config/defconfig_arm-armv7a-linuxapp-gcc
> > > > > > @@ -57,6 +57,7 @@ CONFIG_RTE_LIBRTE_ACL=n
> > > > > > CONFIG_RTE_LIBRTE_LPM=n
> > > > > > CONFIG_RTE_LIBRTE_TABLE=n
> > > > > > CONFIG_RTE_LIBRTE_PIPELINE=n
> > > > > > +CONFIG_RTE_SCHED_VECTOR=n
> > > > > >
> > > > > > # cannot use those on ARM
> > > > > > CONFIG_RTE_KNI_KMOD=n
> > > > > > --
> > > > > > 2.1.0
> > > > > >
> > > > >
> > > > > Hi Jerin,
> > > >
> > > > Hi Jianbo, Thanks for the review.
> > > > Looking forward to seeing contributions to DPDK-ARM.
> > > > We definitely need more hands to make best DPDK-ARM port.
> > > >
> > > > > In this way, we still have to modify two files each time a new feature
> > > > > is added but not verified on ARM architectures.
> > > > > Since disabling those drivers and libs are common for both armv7 and
> > > > > armv8, can you put them in one config file, for example: common_arm?
> > > > >
Hello Jerin and Jianbo.
Do you think that changing a single line in two files (instead of a
single single) is really an issue? I don't think so. At least for now.
I believe (and have already expressed this idea) that this is not a
problem of architecture ports but it is a problem of the build system.
Love me or hate me, in my opinion the build system is broken :). The
build system should be able to solve this.
I've created privately an integration of kconfig into DPDK, however, it
is far from being usable and I did not have time to make at least an
RFC patch. If there is an attitude in the community to include such
thing in the future versions, I'd like to make some more effort in this
area.
For now, the separate armv7/armv8 configuration seems OK to me.
> > > >
> > > > [snip]
> > > >
> > > > 2) AFAIK, PCI NIC PMD's are not yet supported in ARMv7 platform yet
> > > > unlike ARMv8.
> > > > Till we have PCI NIC PMD support, armv7 config needs to be updated
> > > > for each and every new PMD inclusion.
Unfortunately yes. I don't like this state very much...
> > > >
> > > > 3) neon capabilities are bit different in ARMv7 and ARMv8.
> > > > For instance, "vqtbl1q_u8" neon intrinsics is not defined in ARMv7
> > > > which used
> > > > in implementing ACL-NEON. i.e Need additional efforts to extend
> > > > the armv8 neon code to armv7(or vice versa).So it's better to
> > > > have fine control on the config file to enable selective features
> > > >
> > >
> > > The differences between ARMv7 and ARMv8 can't justify we only add new
> > > config for ARMv8. And this file is trying to disable drivers and libs
> > > which is not supported on ARM platforms for now.
> > >
> >
> > I thought difference and point 3 should justify the need for different
> > config. No?
I vote yes.
> > [snip]
> > >
> >
> > I was thinking to have the common_arm64 file so that "FreeBSD, arm compiler,
> > clang, llvm" future version can include it directly.
> > But I agree with you. defconfig_arm64-armv8a-linuxapp-gcc can be treated as
> > a
> > config for a common file for defconfig_arm64-*-linuxapp-gcc(anyway its same,
> > just the toolchain added in defconfig_arm64-*-linuxapp-gcc)
> > I will send out new version with defconfig_arm64-armv8a-linuxapp-gcc
> > as the base instead of common_arm64 file.
I think that unless we support more compilers/operating systems (and
this will take some time), there is no need to consider more general
configurations. I agree to stay with the a
[dpdk-dev] Query on Filtering Support in DPDK
Hi, 2015-11-30 18:19, Rahul Lakkireddy: > 1. Add a new action 'switch' that will: >* Allow re-direction to different ports in hardware. > >Also, for such a rule, additionally support below: > >* Allow source mac/destination mac and vlan header re-writing to be > done by the hardware. > >* Allow re-write of TCP/IP headers to perform NAT in hardware. > > 2. Add ability to mask individual fields at a particular layer for each >filter in flow_director. For example, mask all ip packets coming from >a particular subnet mask and particular range of l4 ports for each >filter rule. > > We would like to get some suggestions on how to proceed with adding the > above features. You need to identify which API must change and what will be the ABI changes. Then please send a deprecation notice before December 11 in order to be part of the 2.2 release notes. If you have some RFC patches to send (at least the API changes), it would be a good discussion start. Thanks
[dpdk-dev] [PATCH v3 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm
2015-11-30 14:27, Jan Viktorin: > I believe (and have already expressed this idea) that this is not a > problem of architecture ports but it is a problem of the build system. > Love me or hate me, in my opinion the build system is broken :). The > build system should be able to solve this. > > I've created privately an integration of kconfig into DPDK, however, it > is far from being usable and I did not have time to make at least an > RFC patch. If there is an attitude in the community to include such > thing in the future versions, I'd like to make some more effort in this > area. If we were integrating kconfig, we should consider kconfig-frontends (http://ymorin.is-a-geek.org/projects/kconfig-frontends). But I'm not sure it is the way to go. You are welcome to open the debate in a dedicated thread by explaining the benefits compared to a configuration script. I think most of the options could be automatically guessed given the target CPU, kernel, libc and compiler. It looks like a scripting task, not a manual configuration (as kconfig provides). But maybe we can mix kconfig and some automatic defaults.
[dpdk-dev] [PATCH v3 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm
On Mon, 30 Nov 2015 14:59:45 +0100 Thomas Monjalon wrote: > 2015-11-30 14:27, Jan Viktorin: > > I believe (and have already expressed this idea) that this is not a > > problem of architecture ports but it is a problem of the build system. > > Love me or hate me, in my opinion the build system is broken :). The > > build system should be able to solve this. > > > > I've created privately an integration of kconfig into DPDK, however, it > > is far from being usable and I did not have time to make at least an > > RFC patch. If there is an attitude in the community to include such > > thing in the future versions, I'd like to make some more effort in this > > area. > > If we were integrating kconfig, we should consider kconfig-frontends > (http://ymorin.is-a-geek.org/projects/kconfig-frontends). True, this seems to be the easiest way. I've already used it successfully. > But I'm not sure it is the way to go. You are welcome to open the debate > in a dedicated thread by explaining the benefits compared to a configuration > script. OK. I will consider this. Probably, after the community call... (Or before?) > I think most of the options could be automatically guessed given the target > CPU, kernel, libc and compiler. It looks like a scripting task, not a > manual configuration (as kconfig provides). But maybe we can mix kconfig > and some automatic defaults. > Well, scripting... If you have issues like "feature X" does not work on "platform A" then you need to express this. If you try to script such dependency, I am afraid you always end up with a system of the same or equivalent complexity as the kconfig already has :). We'll see... Regards Jan -- Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] [PATCH v4] ip_pipeline: add flow id parameter to flow classification
This patch adds flow id field to the flow
classification table entries and adds table action
handlers to read flow id from table entry and
write it into the packet meta-data. The flow_id
(32-bit) parameter is also added to CLI commands
flow add, flow delete, etc.
*v2
fixed bug: flow table entry size power of 2
*v3
fixed bug: changed LRU hash table operation to
extendible bucket hash table operation
*v4
Coverity issue: 120147
Fixes: 7122d30131ad ("examples/ip_pipeline: rework flow classification
pipeline")
Signed-off-by: Jasvinder Singh
Acked-by: Cristian Dumitrescu
---
.../pipeline/pipeline_flow_classification.c| 206 ++---
.../pipeline/pipeline_flow_classification.h| 4 +-
.../pipeline/pipeline_flow_classification_be.c | 148 +--
.../pipeline/pipeline_flow_classification_be.h | 2 +
4 files changed, 316 insertions(+), 44 deletions(-)
diff --git a/examples/ip_pipeline/pipeline/pipeline_flow_classification.c
b/examples/ip_pipeline/pipeline/pipeline_flow_classification.c
index 4b82180..04b6915 100644
--- a/examples/ip_pipeline/pipeline/pipeline_flow_classification.c
+++ b/examples/ip_pipeline/pipeline/pipeline_flow_classification.c
@@ -152,6 +152,7 @@ app_pipeline_fc_key_convert(struct pipeline_fc_key *key_in,
struct app_pipeline_fc_flow {
struct pipeline_fc_key key;
uint32_t port_id;
+ uint32_t flow_id;
uint32_t signature;
void *entry_ptr;
@@ -280,7 +281,8 @@ int
app_pipeline_fc_add(struct app_params *app,
uint32_t pipeline_id,
struct pipeline_fc_key *key,
- uint32_t port_id)
+ uint32_t port_id,
+ uint32_t flow_id)
{
struct app_pipeline_fc *p;
struct app_pipeline_fc_flow *flow;
@@ -325,6 +327,7 @@ app_pipeline_fc_add(struct app_params *app,
req->subtype = PIPELINE_FC_MSG_REQ_FLOW_ADD;
app_pipeline_fc_key_convert(key, req->key, &signature);
req->port_id = port_id;
+ req->flow_id = flow_id;
/* Send request and wait for response */
rsp = app_msg_send_recv(app, pipeline_id, req, MSG_TIMEOUT_DEFAULT);
@@ -348,6 +351,7 @@ app_pipeline_fc_add(struct app_params *app,
memset(&flow->key, 0, sizeof(flow->key));
memcpy(&flow->key, key, sizeof(flow->key));
flow->port_id = port_id;
+ flow->flow_id = flow_id;
flow->signature = signature;
flow->entry_ptr = rsp->entry_ptr;
@@ -370,6 +374,7 @@ app_pipeline_fc_add_bulk(struct app_params *app,
uint32_t pipeline_id,
struct pipeline_fc_key *key,
uint32_t *port_id,
+ uint32_t *flow_id,
uint32_t n_keys)
{
struct app_pipeline_fc *p;
@@ -389,6 +394,7 @@ app_pipeline_fc_add_bulk(struct app_params *app,
if ((app == NULL) ||
(key == NULL) ||
(port_id == NULL) ||
+ (flow_id == NULL) ||
(n_keys == 0))
return -1;
@@ -496,6 +502,7 @@ app_pipeline_fc_add_bulk(struct app_params *app,
flow_req[i].key,
&signature[i]);
flow_req[i].port_id = port_id[i];
+ flow_req[i].flow_id = flow_id[i];
}
req->type = PIPELINE_MSG_REQ_CUSTOM;
@@ -535,6 +542,7 @@ app_pipeline_fc_add_bulk(struct app_params *app,
for (i = 0; i < rsp->n_keys; i++) {
memcpy(&flow[i]->key, &key[i], sizeof(flow[i]->key));
flow[i]->port_id = port_id[i];
+ flow[i]->flow_id = flow_id[i];
flow[i]->signature = signature[i];
flow[i]->entry_ptr = flow_rsp[i].entry_ptr;
@@ -731,13 +739,15 @@ print_fc_qinq_flow(struct app_pipeline_fc_flow *flow)
{
printf("(SVLAN = %" PRIu32 ", "
"CVLAN = %" PRIu32 ") => "
- "Port = %" PRIu32 " "
+ "Port = %" PRIu32 ", "
+ "Flow ID = %" PRIu32 ", "
"(signature = 0x%08" PRIx32 ", "
"entry_ptr = %p)\n",
flow->key.key.qinq.svlan,
flow->key.key.qinq.cvlan,
flow->port_id,
+ flow->flow_id,
flow->signature,
flow->entry_ptr);
}
@@ -750,7 +760,8 @@ print_fc_ipv4_5tuple_flow(struct app_pipeline_fc_flow *flow)
"SP = %" PRIu32 ", "
"DP = %" PRIu32 ", "
"Proto = %" PRIu32 ") => "
- "Port = %" PRIu32 " "
+ "Port = %" PRIu32 ", "
+ "Flow ID = %" PRIu32 " "
"(signature = 0x%08" PRIx32 ", "
"entry_ptr = %p)\n",
@@ -770,6 +781,7 @@ print_fc_ipv4_5tuple_flow(struct app_pipeline_fc_flow *flow)
flow->key.key.ipv4_5tuple.proto,
flow->port_id,
+ flow->flow_id,
flow->signature,
flow->entry_ptr);
}
@@ -787,7 +799,8 @@ print_fc_ipv6_5tuple_flow(struct
[dpdk-dev] [PATCH v3 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm
2015-11-30 15:04, Jan Viktorin: > On Mon, 30 Nov 2015 14:59:45 +0100 > Thomas Monjalon wrote: > > > 2015-11-30 14:27, Jan Viktorin: > > > I believe (and have already expressed this idea) that this is not a > > > problem of architecture ports but it is a problem of the build system. > > > Love me or hate me, in my opinion the build system is broken :). The > > > build system should be able to solve this. > > > > > > I've created privately an integration of kconfig into DPDK, however, it > > > is far from being usable and I did not have time to make at least an > > > RFC patch. If there is an attitude in the community to include such > > > thing in the future versions, I'd like to make some more effort in this > > > area. > > > > If we were integrating kconfig, we should consider kconfig-frontends > > (http://ymorin.is-a-geek.org/projects/kconfig-frontends). > > True, this seems to be the easiest way. I've already used it > successfully. > > > But I'm not sure it is the way to go. You are welcome to open the debate > > in a dedicated thread by explaining the benefits compared to a configuration > > script. > > OK. I will consider this. Probably, after the community call... (Or > before?) Please take your time. We will better ready to discuss it when the "make install" issue will be solved. > > I think most of the options could be automatically guessed given the target > > CPU, kernel, libc and compiler. It looks like a scripting task, not a > > manual configuration (as kconfig provides). But maybe we can mix kconfig > > and some automatic defaults. > > > > Well, scripting... If you have issues like "feature X" does not work > on "platform A" then you need to express this. If you try to script > such dependency, I am afraid you always end up with a system of the same > or equivalent complexity as the kconfig already has :). We'll see... I'm not speaking about complexity here, but just features. With kconfig, options and dependencies are well described but the defaults are fixed. With a script, you can have some dynamically generated defaults. Please expose the needs and features clearly in another thread. Thanks
[dpdk-dev] [PATCH] reserve 'make install' for future use
2015-11-30 14:26, Panu Matilainen: > On 11/27/2015 07:33 PM, Thomas Monjalon wrote: > > 2015-11-25 10:48, Panu Matilainen: > >> On 11/24/2015 06:54 PM, Bruce Richardson wrote: > >>> On Fri, Nov 06, 2015 at 02:04:54PM +0100, Thomas Monjalon wrote: > 2015-11-06 12:57, Bruce Richardson: > > So, any thoughts or comments on this? There has been lots of discussion > > in this > > general area but nothing yet going into the release to try and improve > > the situation. > > > > Are we just going to kick the problem down the road to the 2.3 release? > > I plan to check these patches in the coming days for an integration in > 2.2. > > >>> Anything further on this? > >>> Any thoughts from anyone else about this whole area of a saner > >>> build/install > >>> system for DPDK and the various patches floating around. > >> > >> Well, it seems we wont have a sane "make install" in 2.2 yet, but this > >> is at least a step in the right direction so +1 from me. > > > > Why is it a step in the right direction? > > Right direction as in, everybody seems to agree we want "make install" > ultimately do the right thing. If we can't have it in 2.2 yet then a > preparatory step is better than not having it. Yes sure. We will have something in 2.2. The question is what :) > > What have I missed? > > Perhaps its me who has missed the fact that 2.2 is still open for these > kind of things. Yes we still have more than one week before closing the release. We can try some changes in the build system. > If it were up to me, I think I'd just apply Marios latest patch series > (perhaps condence it somewhat) to get it over with, fine-tune later > if/as necessary. This is veering to the side of bikeshedding real fast. > > BTW, one noteworthy point is that in all of these related threads, > nobody absolutely nobody has spoken up for the current behavior of "make > install". Which makes me wonder if anybody is actually using it, and > whether all this is just worrying for nothing. Yes we can break some old behaviours. The T= option should be easy to simulate in a single target case.
[dpdk-dev] [PATCH] reserve 'make install' for future use
2015-11-30 11:49, Bruce Richardson: > On Mon, Nov 30, 2015 at 11:41:32AM +, Richardson, Bruce wrote: > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > Sent: Monday, November 30, 2015 11:27 AM > > > To: Richardson, Bruce > > > Cc: Panu Matilainen ; dev at dpdk.org; > > > olivier.matz at 6wind.com > > > Subject: Re: [dpdk-dev] [PATCH] reserve 'make install' for future use > > > > > > 2015-11-30 11:08, Richardson, Bruce: > > > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > > > Why is it a step in the right direction? > > > > > > > > > > We just need to install the files in a different hierarchy and adapt > > > > > the makefiles to be able to compile an application while keeping the > > > > > RTE_SDK variable to specify the root directory (previously built > > > > > thanks to DESTDIR). > > > > > As the hierarchy could be tuned, we need more variables, e.g.: > > > > > DPDK_INC_DIR (default = RTE_SDK/include/dpdk) > > > > > DPDK_LIB_DIR (default = RTE_SDK/lib) > > > > > > > > > > While doing it, we can have a specific handling of T= to keep > > > > > compatibility with the current (old) syntax. > > > > > > > > > > What have I missed? > > > > > > > > I'm not sure our existing "make install" is suitable for use for this, > > > without having it heavily overloaded. The existing T= behavior has support > > > for wildcards and compiling multiple instances at the same time - > > > something that won't work with a scheme to actually install DPDK > > > throughout the filesystem hierarchy. Having it sometimes behave as now, > > > and sometimes behave as a standard make install is a bad idea IMHO, as it > > > confuses things. Having lots of extra environment variables is also not a > > > great idea, to my mind. > > > > > > Yes I agree. > > > I forgot to mention it, but in my idea, we can drop the support for > > > multiple targets. So the T= compatibility would be only a shortcut to do > > > "make config" and name the build directory based on the template name. > > > > > > About the environment variables: > > > An application requires CFLAGS and LDFLAGS (at least). The standard way to > > > provide them is pkgconfig (not implemented yet). > > > For applications using the DPDK makefiles, the only input is RTE_SDK. > > > When allowing more tuning in paths, we need more variables when using the > > > DPDK makefiles to build an application. > > > > > > > My opinion is that we should rename our existing "make install" to > > > something more suitable - my patch suggestion was "make sdk" but it could > > > be "make target" or something else if people prefer. Once that is done, we > > > can then look to implement a proper "make install" command that works in a > > > standard way, perhaps alongside a configure script of some description. > > > > > > I think we don't need to rename or move some code. > > > Just drop and replace some of them. > > > > > > The configure script is a great idea but it is a totally different idea. > > > I do not think that installation and configuration should be related. > > > Please let's consider "make install" first. > > > > > > > For an easy enough solution, I would look to apply this patch to create > > > "make sdk" and also http://dpdk.org/dev/patchwork/patch/8076/ to have a > > > "make install" command that works in the build dir. That way: > > > > * you can have existing behavior using "make sdk T=" > > > > * you can have standard(ish) configure/make/make install behavior using: > > > > make config T= > > > > cd build > > > > make > > > > make install > > > > and the "make config" step can subsequently be wrapped in a configure > > > script to eliminate the need to know what the best target to use is, etc. > > > > > > As Panu commented, I do not think it is a good idea to have different > > > behaviours inside and outside of the build directory. > > > I would even say that this embedded makefile is only confusing and should > > > be dropped. > > > We need to have *one* right building methods, not to bring more confusion. > > > > I disagree. I don't think we can have *one* right building method, because > > to > > do so means completely throwing away our existing methods of building DPDK > > and using sample applications. That general method, using RTE_SDK and > > RTE_TARGET > > needs to be supported for some time for those projects already familiar > > with it > > and using it. We can keep it for some time while allowing other tree hierarchies. > > As well as this, we also need a sane way of building DPDK inside the > > "build" > > directory, and having a "make install" target that installs the libraries > > and headers inside /usr/local (or whatever was specified as $prefix). > > > > With regards to different behavior, since different targets are provided, I > > don't see it as a problem. In the root directory, "make config" and "make > > sdk" > > are provided for backward compatibilit
[dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script
On Wed, Nov 25, 2015 at 08:08:37AM -0800, Stephen Hemminger wrote: > On Wed, 25 Nov 2015 10:38:48 +0200 > Panu Matilainen wrote: > > > On 11/25/2015 12:46 AM, Stephen Hemminger wrote: > > > On Tue, 24 Nov 2015 16:31:17 +0200 > > > Panu Matilainen wrote: > > > > > >> The physically linked-together combined library has been an increasing > > >> source of problems, as was predicted when library and symbol versioning > > >> was introduced. Replace the complex and fragile construction with a > > >> simple linker script which achieves the same without all the problems, > > >> remove the related kludges from eg mlx drivers. > > >> > > >> Since creating the linker script is practically zero cost, remove the > > >> config option and just create it always. > > >> > > >> Based on a patch by Sergio Gonzales Monroy, linker script approach > > >> initially suggested by Neil Horman. > > >> > > >> Suggested-by: Sergio Gonzalez Monroy > >> intel.com> > > >> Suggested-by: Neil Horman > > >> Signed-off-by: Panu Matilainen > > > > > > But it now means distros have to ship 20 libraries which seems like > > > a step back. > > > > That's how Fedora and RHEL are shipping it already and nobody has so > > much as noticed anything strange, much less complained about it. 20 > > libraries is but a drop in the ocean on a average distro. But more to > > the point, distros will prefer 50 working libraries over one that doesn't. > > > > The combined library as it is simply is no longer a viable option. > > Besides just being broken (witness the strange hacks people are coming > > up with to work around issues in it) its ugly because it basically gives > > the middle finger to all the effort going into version compatibility, > > and its also big. Few projects will use every library in DPDK, but with > > the combined library they're forced to lug the 800 pound gorilla along > > needlessly. > > > > - Panu - > > > > Fixing the combined library took less than an hour for us. How did you fix the versioning issue? Neil
[dpdk-dev] [PATCH] librte_port: fix mbuf allocation in source port and missing
This patch fixes two issues:
- The allocated mbufs in rte_port_source_rx() are not initialized properly
issue. This issue caused the mbufs not be able to freed back to mempool by
rte_pktmbuf_free().
- The missed sink port statistics issue. Sink port was not able record the
number of mbufs received/dropped.
Signed-off-by: Fan Zhang
Acked-by: Cristian Dumitrescu
---
lib/librte_port/rte_port_source_sink.c | 68 +-
1 file changed, 66 insertions(+), 2 deletions(-)
diff --git a/lib/librte_port/rte_port_source_sink.c
b/lib/librte_port/rte_port_source_sink.c
index 234ab18..babecd7 100644
--- a/lib/librte_port/rte_port_source_sink.c
+++ b/lib/librte_port/rte_port_source_sink.c
@@ -105,10 +105,16 @@ static int
rte_port_source_rx(void *port, struct rte_mbuf **pkts, uint32_t n_pkts)
{
struct rte_port_source *p = (struct rte_port_source *) port;
+ uint32_t i;
if (rte_mempool_get_bulk(p->mempool, (void **) pkts, n_pkts) != 0)
return 0;
+ for (i = 0; i < n_pkts; i++) {
+ rte_mbuf_refcnt_set(pkts[i], 1);
+ rte_pktmbuf_reset(pkts[i]);
+ }
+
RTE_PORT_SOURCE_STATS_PKTS_IN_ADD(p, n_pkts);
return n_pkts;
@@ -133,17 +139,48 @@ rte_port_source_stats_read(void *port,
/*
* Port SINK
*/
+#ifdef RTE_PORT_STATS_COLLECT
+
+#define RTE_PORT_SINK_STATS_PKTS_IN_ADD(port, val) \
+ (port->stats.n_pkts_in += val)
+#define RTE_PORT_SINK_STATS_PKTS_DROP_ADD(port, val) \
+ (port->stats.n_pkts_drop += val)
+
+#else
+
+#define RTE_PORT_SINK_STATS_PKTS_IN_ADD(port, val)
+#define RTE_PORT_SINK_STATS_PKTS_DROP_ADD(port, val)
+
+#endif
+
+struct rte_port_sink {
+ struct rte_port_out_stats stats;
+};
+
static void *
rte_port_sink_create(__rte_unused void *params, __rte_unused int socket_id)
{
- return (void *) 1;
+ struct rte_port_sink *port;
+
+ /* Memory allocation */
+ port = rte_zmalloc_socket("PORT", sizeof(*port),
+ RTE_CACHE_LINE_SIZE, socket_id);
+ if (port == NULL) {
+ RTE_LOG(ERR, PORT, "%s: Failed to allocate port\n", __func__);
+ return NULL;
+ }
+
+ return port;
}
static int
rte_port_sink_tx(__rte_unused void *port, struct rte_mbuf *pkt)
{
- rte_pktmbuf_free(pkt);
+ __rte_unused struct rte_port_sink *p = (struct rte_port_sink *) port;
+ RTE_PORT_SINK_STATS_PKTS_IN_ADD(p, 1);
+ rte_pktmbuf_free(pkt);
+ RTE_PORT_SINK_STATS_PKTS_DROP_ADD(p, 1);
return 0;
}
@@ -151,29 +188,55 @@ static int
rte_port_sink_tx_bulk(__rte_unused void *port, struct rte_mbuf **pkts,
uint64_t pkts_mask)
{
+ __rte_unused struct rte_port_sink *p = (struct rte_port_sink *) port;
+
if ((pkts_mask & (pkts_mask + 1)) == 0) {
uint64_t n_pkts = __builtin_popcountll(pkts_mask);
uint32_t i;
+ RTE_PORT_SINK_STATS_PKTS_IN_ADD(p, n_pkts);
+
for (i = 0; i < n_pkts; i++) {
struct rte_mbuf *pkt = pkts[i];
rte_pktmbuf_free(pkt);
}
+
+ RTE_PORT_SINK_STATS_PKTS_DROP_ADD(p, n_pkts);
} else {
+
+
for ( ; pkts_mask; ) {
uint32_t pkt_index = __builtin_ctzll(pkts_mask);
uint64_t pkt_mask = 1LLU << pkt_index;
struct rte_mbuf *pkt = pkts[pkt_index];
+ RTE_PORT_SINK_STATS_PKTS_IN_ADD(p, 1);
rte_pktmbuf_free(pkt);
pkts_mask &= ~pkt_mask;
+ RTE_PORT_SINK_STATS_PKTS_DROP_ADD(p, 1);
}
}
return 0;
}
+static int
+rte_port_sink_stats_read(void *port, struct rte_port_out_stats *stats,
+ int clear)
+{
+ struct rte_port_sink *p =
+ (struct rte_port_sink *) port;
+
+ if (stats != NULL)
+ memcpy(stats, &p->stats, sizeof(p->stats));
+
+ if (clear)
+ memset(&p->stats, 0, sizeof(p->stats));
+
+ return 0;
+}
+
/*
* Summary of port operations
*/
@@ -190,4 +253,5 @@ struct rte_port_out_ops rte_port_sink_ops = {
.f_tx = rte_port_sink_tx,
.f_tx_bulk = rte_port_sink_tx_bulk,
.f_flush = NULL,
+ .f_stats = rte_port_sink_stats_read,
};
--
2.5.0
[dpdk-dev] [PATCH] librte_port: fix mbuf allocation in source port and missing
Hi, 2015-11-30 15:46, Fan Zhang: > This patch fixes two issues: > - The allocated mbufs in rte_port_source_rx() are not initialized properly > issue. This issue caused the mbufs not be able to freed back to mempool by > rte_pktmbuf_free(). > - The missed sink port statistics issue. Sink port was not able record the > number of mbufs received/dropped. > > Signed-off-by: Fan Zhang > Acked-by: Cristian Dumitrescu It seems you should send 2 patches. Please use the "Fixes:" keyword to specify the commit introducing the bug. Thanks
[dpdk-dev] Unable to configure ethdev in secondary process using ring PMD
Hello, I would like to setup communication between two existing DPDK applications and run them on the same host. "Connecting their ports" in some way in order not to rewrite the applications would be very desirable. Specifically, I would like one process to send packets and the second process to receive the packets using rte_eth_tx_burst() and rte_eth_rx_burst() respectively. The most straightforward way to accomplish this seems to be by using ring based PMD API as described in the documentation [1] and email [2]. To adapt the example from the documentation to multi-process scenario, I call rte_ring_create() and rte_eth_from_rings() in the primary process, rte_ring_lookup() and rte_eth_from_rings() in the secondary process. After that each process calls rte_eth_dev_configure(). Unfortunately, the function returns -1001 in the secondary process, which is explained in debug log: PMD: rte_eth_dev_configure: Cannot run in secondary processes Is it possible to connect the applications as described above? Any advice would be appreciated. References: 1. Network Interface Controller Drivers. Chapter 8. Libpcap and Ring Based Poll Mode Drivers. 2. DPDK ML. Fri Dec 6 07:22:06 CET 2013. How to know corresponding device from port number. Tetsuya.Mukawa Thanks, Alexey Bogdanenko
[dpdk-dev] [PATCH v6 06/10] mk: Add rule for installing sdk files
Hi, 2015-11-10 11:07, Mario Carrillo: > Add hierarchy-file support to the DPDK makefiles, scripts, > examples, tools, config files and headers, > when invoking "make install-sdk" makefiles, scripts, > examples, tools, config files will be installed in: The tools are part of the runtime, not the sdk. > $(DESTDIR)/$(SDK_DIR) > and headers will be installed in: > $(DESTDIR)/$(INCLUDE_DIR) > where SDK_DIR=$(RTE_PREFIX)/share/dpdk, > INCLUDE_DIR=$(RTE_PREFIX)/include/dpdk > RTE_PREFIX=/usr/local by default, you can override RTE_PREFIX, SDK_DIR > and INCLUDE_DIR vars. > This hierarchy is based on: > http://www.freedesktop.org/software/systemd/man/file-hierarchy.html It would be better to follow the GNU standard to name the variables: https://www.gnu.org/prep/standards/html_node/Directory-Variables.html https://www.gnu.org/prep/standards/html_node/DESTDIR.html prefix ?= /usr/local exec_prefix ?= $(prefix) bindir ?= $(exec_prefix)/bin sbindir ?= $(exec_prefix)/sbin libdir ?= $(exec_prefix)/lib includedir ?= $(prefix)/include/dpdk datarootdir ?= $(prefix)/share docdir ?= $(datarootdir)/doc/dpdk datadir ?= $(datarootdir)/dpdk I would add: kerneldir ?= $(exec_prefix)/kmod sdkdir ?= $(datadir)
[dpdk-dev] [PATCH v6 06/10] mk: Add rule for installing sdk files
Thank you for your feedback Thomas, I'm going to take note for a version 6 patches :) Mario. From: Thomas Monjalon [thomas.monja...@6wind.com] Sent: Monday, November 30, 2015 8:20 AM To: Arevalo, Mario Alfredo C Cc: dev at dpdk.org; Venegas Munoz, Jos C Subject: Re: [dpdk-dev] [PATCH v6 06/10] mk: Add rule for installing sdk files Hi, 2015-11-10 11:07, Mario Carrillo: > Add hierarchy-file support to the DPDK makefiles, scripts, > examples, tools, config files and headers, > when invoking "make install-sdk" makefiles, scripts, > examples, tools, config files will be installed in: The tools are part of the runtime, not the sdk. > $(DESTDIR)/$(SDK_DIR) > and headers will be installed in: > $(DESTDIR)/$(INCLUDE_DIR) > where SDK_DIR=$(RTE_PREFIX)/share/dpdk, > INCLUDE_DIR=$(RTE_PREFIX)/include/dpdk > RTE_PREFIX=/usr/local by default, you can override RTE_PREFIX, SDK_DIR > and INCLUDE_DIR vars. > This hierarchy is based on: > http://www.freedesktop.org/software/systemd/man/file-hierarchy.html It would be better to follow the GNU standard to name the variables: https://www.gnu.org/prep/standards/html_node/Directory-Variables.html https://www.gnu.org/prep/standards/html_node/DESTDIR.html prefix ?= /usr/local exec_prefix ?= $(prefix) bindir ?= $(exec_prefix)/bin sbindir ?= $(exec_prefix)/sbin libdir ?= $(exec_prefix)/lib includedir ?= $(prefix)/include/dpdk datarootdir ?= $(prefix)/share docdir ?= $(datarootdir)/doc/dpdk datadir ?= $(datarootdir)/dpdk I would add: kerneldir ?= $(exec_prefix)/kmod sdkdir ?= $(datadir)
[dpdk-dev] [PATCH] i40evf: fix mac deletion when stop dev
On Mon, 30 Nov 2015 11:54:09 +0800 Jingjing Wu wrote: > + (void)rte_memcpy(mac_addr.addr_bytes, hw->mac.addr, > + sizeof(mac_addr.addr_bytes)) Please don't add useless (void) cast. I haven't seen that since lint on Unix.
[dpdk-dev] [PATCH v3 0/2] disable CONFIG_RTE_SCHED_VECTOR for arm
On Fri, 27 Nov 2015 19:04:26 +0530 Jerin Jacob wrote: > v1..v2 > created common arm64 configs under common_arm64 file. > let each armv8 machine targets capture only the differences > between the common arm64 config. > > v2..v3 > Fix whitespace issue with git am > > Jerin Jacob (2): > config: arm64: create common arm64 configs under common_arm64 file > config: disable CONFIG_RTE_SCHED_VECTOR for arm > > config/common_arm64 | 49 > > config/defconfig_arm-armv7a-linuxapp-gcc | 1 + > config/defconfig_arm64-armv8a-linuxapp-gcc | 18 +- > config/defconfig_arm64-thunderx-linuxapp-gcc | 18 +- > config/defconfig_arm64-xgene1-linuxapp-gcc | 18 +- > 5 files changed, 53 insertions(+), 51 deletions(-) > create mode 100644 config/common_arm64 > Since the RTE_SCHED_VECTOR is lightly tested and doesn't provide really significant performance improvement, it should probably be disabled by default on all platforms.
[dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script
On Mon, 30 Nov 2015 10:03:43 -0500 Neil Horman wrote: > On Wed, Nov 25, 2015 at 08:08:37AM -0800, Stephen Hemminger wrote: > > On Wed, 25 Nov 2015 10:38:48 +0200 > > Panu Matilainen wrote: > > > > > On 11/25/2015 12:46 AM, Stephen Hemminger wrote: > > > > On Tue, 24 Nov 2015 16:31:17 +0200 > > > > Panu Matilainen wrote: > > > > > > > >> The physically linked-together combined library has been an increasing > > > >> source of problems, as was predicted when library and symbol versioning > > > >> was introduced. Replace the complex and fragile construction with a > > > >> simple linker script which achieves the same without all the problems, > > > >> remove the related kludges from eg mlx drivers. > > > >> > > > >> Since creating the linker script is practically zero cost, remove the > > > >> config option and just create it always. > > > >> > > > >> Based on a patch by Sergio Gonzales Monroy, linker script approach > > > >> initially suggested by Neil Horman. > > > >> > > > >> Suggested-by: Sergio Gonzalez Monroy > > >> intel.com> > > > >> Suggested-by: Neil Horman > > > >> Signed-off-by: Panu Matilainen > > > > > > > > But it now means distros have to ship 20 libraries which seems like > > > > a step back. > > > > > > That's how Fedora and RHEL are shipping it already and nobody has so > > > much as noticed anything strange, much less complained about it. 20 > > > libraries is but a drop in the ocean on a average distro. But more to > > > the point, distros will prefer 50 working libraries over one that doesn't. > > > > > > The combined library as it is simply is no longer a viable option. > > > Besides just being broken (witness the strange hacks people are coming > > > up with to work around issues in it) its ugly because it basically gives > > > the middle finger to all the effort going into version compatibility, > > > and its also big. Few projects will use every library in DPDK, but with > > > the combined library they're forced to lug the 800 pound gorilla along > > > needlessly. > > > > > > - Panu - > > > > > > > Fixing the combined library took less than an hour for us. > How did you fix the versioning issue? > > Neil This is what I did. Also decided to keep shared library version == major DPDK version to avoid confusion. mk: fix when building combined shared library The DPDK mk file does not set shared object name or version information as required by Debian. Signed-off-by: Stephen Hemminger --- a/mk/rte.sharelib.mk +++ b/mk/rte.sharelib.mk @@ -51,10 +51,10 @@ ifeq ($(LINK_USING_CC),1) # Override the definition of LD here, since we're linking with CC LD := $(CC) $(CPU_CFLAGS) O_TO_S = $(LD) $(call linkerprefix,$(CPU_LDFLAGS)) \ - -shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE) + -shared $(OBJS) -Wl,-soname,$(LIB_ONE).$(RTE_LIBVERS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE) else O_TO_S = $(LD) $(CPU_LDFLAGS) \ - -shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE) + -shared $(OBJS) -soname $(LIB_ONE).$(RTE_LIBVERS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE) endif O_TO_S_STR = $(subst ','\'',$(O_TO_S)) #'# fix syntax highlight --- a/mk/rte.vars.mk +++ b/mk/rte.vars.mk @@ -74,8 +74,10 @@ ifneq ($(BUILDING_RTE_SDK),) endif RTE_LIBNAME := $(CONFIG_RTE_LIBNAME:"%"=%) +RTE_LIBVERS := $(CONFIG_RTE_LIBVERS:"%"=%) ifeq ($(RTE_LIBNAME),) RTE_LIBNAME := intel_dpdk +RTE_LIBVERS := 2 endif # RTE_TARGET is deducted from config when we are building the SDK.
[dpdk-dev] Unable to configure ethdev in secondary process using ring PMD
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Alexey Bogdanenko > Sent: Monday, November 30, 2015 4:17 PM > To: dev at dpdk.org > Subject: [dpdk-dev] Unable to configure ethdev in secondary process using > ring PMD > > Hello, > > I would like to setup communication between two existing DPDK applications > and run them on the same host. > > "Connecting their ports" in some way in order not to rewrite the > applications would be very desirable. Specifically, I would like one > process to send packets and the second process to receive the packets > using rte_eth_tx_burst() and rte_eth_rx_burst() respectively. > > The most straightforward way to accomplish this seems to be by using ring > based PMD API as described in the documentation [1] and email [2]. > To adapt the example from the documentation to multi-process scenario, I > call rte_ring_create() and rte_eth_from_rings() in the primary process, > rte_ring_lookup() and rte_eth_from_rings() in the secondary process. > After that each process calls rte_eth_dev_configure(). > > Unfortunately, the function returns -1001 in the secondary process, which > is explained in debug log: > > PMD: rte_eth_dev_configure: Cannot run in secondary processes > > Is it possible to connect the applications as described above? Any advice > would be appreciated. > > References: > > 1. Network Interface Controller Drivers. Chapter 8. > Libpcap and Ring Based Poll Mode Drivers. > > 2. DPDK ML. Fri Dec 6 07:22:06 CET 2013. How to know corresponding device > from port number. Tetsuya.Mukawa > > Thanks, > > Alexey Bogdanenko Hi Alexey, The ring PMDs returned from eth_from_rings should be all ready to be used without having to explicitly configure it or set up the queues. /Bruce
[dpdk-dev] [PATCH v4 0/2] disable CONFIG_RTE_SCHED_VECTOR for arm
v1..v2 created common arm64 configs under common_arm64 file. let each armv8 machine targets capture only the differences between the common arm64 config. v2..v3 Fix whitespace issue with git am v3..v4 removed common_arm64 file and used defconfig_arm64-armv8a-linuxapp-gcc as base Jerin Jacob (2): config: use defconfig_arm64-armv8a-linuxapp-gcc as base for arm64 targets config: disable CONFIG_RTE_SCHED_VECTOR for arm config/defconfig_arm-armv7a-linuxapp-gcc | 1 + config/defconfig_arm64-armv8a-linuxapp-gcc | 1 + config/defconfig_arm64-thunderx-linuxapp-gcc | 22 +- config/defconfig_arm64-xgene1-linuxapp-gcc | 24 +--- 4 files changed, 4 insertions(+), 44 deletions(-) -- 2.1.0
[dpdk-dev] [PATCH v4 1/2] config: use defconfig_arm64-armv8a-linuxapp-gcc as base for arm64 targets
let each armv8 machine targets capture only the differences between the common defconfig_arm64-armv8a-linuxapp-gcc Suggested-by: Thomas Monjalon Signed-off-by: Jerin Jacob --- config/defconfig_arm64-thunderx-linuxapp-gcc | 22 +- config/defconfig_arm64-xgene1-linuxapp-gcc | 24 +--- 2 files changed, 2 insertions(+), 44 deletions(-) diff --git a/config/defconfig_arm64-thunderx-linuxapp-gcc b/config/defconfig_arm64-thunderx-linuxapp-gcc index 6b2048b..fe5e987 100644 --- a/config/defconfig_arm64-thunderx-linuxapp-gcc +++ b/config/defconfig_arm64-thunderx-linuxapp-gcc @@ -29,28 +29,8 @@ # OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. # -#include "common_linuxapp" +#include "defconfig_arm64-armv8a-linuxapp-gcc" CONFIG_RTE_MACHINE="thunderx" -CONFIG_RTE_ARCH="arm64" -CONFIG_RTE_ARCH_ARM64=y -CONFIG_RTE_ARCH_64=y -CONFIG_RTE_ARCH_ARM_NEON=y - -CONFIG_RTE_FORCE_INTRINSICS=y - -CONFIG_RTE_TOOLCHAIN="gcc" -CONFIG_RTE_TOOLCHAIN_GCC=y - CONFIG_RTE_CACHE_LINE_SIZE=128 - -CONFIG_RTE_IXGBE_INC_VECTOR=n -CONFIG_RTE_LIBRTE_VIRTIO_PMD=n -CONFIG_RTE_LIBRTE_IVSHMEM=n -CONFIG_RTE_LIBRTE_FM10K_PMD=n -CONFIG_RTE_LIBRTE_I40E_PMD=n - -CONFIG_RTE_LIBRTE_LPM=n -CONFIG_RTE_LIBRTE_TABLE=n -CONFIG_RTE_LIBRTE_PIPELINE=n diff --git a/config/defconfig_arm64-xgene1-linuxapp-gcc b/config/defconfig_arm64-xgene1-linuxapp-gcc index d75f8f0..f096166 100644 --- a/config/defconfig_arm64-xgene1-linuxapp-gcc +++ b/config/defconfig_arm64-xgene1-linuxapp-gcc @@ -29,28 +29,6 @@ # OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. # -#include "common_linuxapp" +#include "defconfig_arm64-armv8a-linuxapp-gcc" CONFIG_RTE_MACHINE="xgene1" - -CONFIG_RTE_ARCH="arm64" -CONFIG_RTE_ARCH_ARM64=y -CONFIG_RTE_ARCH_64=y -CONFIG_RTE_ARCH_ARM_NEON=y - -CONFIG_RTE_FORCE_INTRINSICS=y - -CONFIG_RTE_TOOLCHAIN="gcc" -CONFIG_RTE_TOOLCHAIN_GCC=y - -CONFIG_RTE_CACHE_LINE_SIZE=64 - -CONFIG_RTE_IXGBE_INC_VECTOR=n -CONFIG_RTE_LIBRTE_VIRTIO_PMD=n -CONFIG_RTE_LIBRTE_IVSHMEM=n -CONFIG_RTE_LIBRTE_FM10K_PMD=n -CONFIG_RTE_LIBRTE_I40E_PMD=n - -CONFIG_RTE_LIBRTE_LPM=n -CONFIG_RTE_LIBRTE_TABLE=n -CONFIG_RTE_LIBRTE_PIPELINE=n -- 2.1.0
[dpdk-dev] [PATCH v4 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm
Commit 42ec27a0178a causes compiling error on arm, as RTE_SCHED_VECTOR
does support only SSE intrinsic, so disable it till we have neon support.
Fixes: 42ec27a0178a ("sched: enable SSE optimizations in config")
Acked-By: Jan Viktorin
Signed-off-by: Jerin Jacob
---
config/defconfig_arm-armv7a-linuxapp-gcc | 1 +
config/defconfig_arm64-armv8a-linuxapp-gcc | 1 +
2 files changed, 2 insertions(+)
diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc
b/config/defconfig_arm-armv7a-linuxapp-gcc
index 82143af..9924ff9 100644
--- a/config/defconfig_arm-armv7a-linuxapp-gcc
+++ b/config/defconfig_arm-armv7a-linuxapp-gcc
@@ -57,6 +57,7 @@ CONFIG_RTE_LIBRTE_ACL=n
CONFIG_RTE_LIBRTE_LPM=n
CONFIG_RTE_LIBRTE_TABLE=n
CONFIG_RTE_LIBRTE_PIPELINE=n
+CONFIG_RTE_SCHED_VECTOR=n
# cannot use those on ARM
CONFIG_RTE_KNI_KMOD=n
diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc
b/config/defconfig_arm64-armv8a-linuxapp-gcc
index 49e7056..504f3ed 100644
--- a/config/defconfig_arm64-armv8a-linuxapp-gcc
+++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
@@ -54,3 +54,4 @@ CONFIG_RTE_LIBRTE_I40E_PMD=n
CONFIG_RTE_LIBRTE_LPM=n
CONFIG_RTE_LIBRTE_TABLE=n
CONFIG_RTE_LIBRTE_PIPELINE=n
+CONFIG_RTE_SCHED_VECTOR=n
--
2.1.0
[dpdk-dev] [PATCH 0/3] add lpm support for NEON
- Introduce new rte_vect_* abstractions in eal - This patch set has the changes required for optimised pm library usage in arm64 perspective - Tested on Juno and Thunder boards - Tested and verified the changes with following DPDK unit test cases --lpm_autotest --lpm6_autotest - This patch set has dependency on [dpdk-dev] [PATCH v4 0/2] disable CONFIG_RTE_SCHED_VECTOR for arm - With these changes, arm64 platform supports all DPDK libraries(in feature wise) Jerin Jacob (3): eal: introduce rte_vect_* abstractions lpm: add support for NEON maintainers: claim responsibility for arm64 specific files of hash and lpm MAINTAINERS | 3 + app/test/test_lpm.c | 10 +- config/defconfig_arm64-armv8a-linuxapp-gcc| 3 - lib/librte_eal/common/include/arch/arm/rte_vect.h | 17 ++- lib/librte_eal/common/include/arch/x86/rte_vect.h | 8 + lib/librte_lpm/Makefile | 3 + lib/librte_lpm/rte_lpm.h | 5 + lib/librte_lpm/rte_lpm_neon.h | 172 ++ 8 files changed, 212 insertions(+), 9 deletions(-) create mode 100644 lib/librte_lpm/rte_lpm_neon.h -- 2.1.0
[dpdk-dev] [PATCH 1/3] eal: introduce rte_vect_* abstractions
introduce rte_vect_* abstractions to remove SSE/AVX specific
code in the common code(i.e the test applications)
The patch does not provide any functional change for IA, the goal is to
have infrastructure to reuse the common vector-based test code across
all the architectures.
Signed-off-by: Jerin Jacob
---
lib/librte_eal/common/include/arch/arm/rte_vect.h | 17 -
lib/librte_eal/common/include/arch/x86/rte_vect.h | 8
2 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/lib/librte_eal/common/include/arch/arm/rte_vect.h
b/lib/librte_eal/common/include/arch/arm/rte_vect.h
index 21cdb4d..d300951 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_vect.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_vect.h
@@ -33,13 +33,14 @@
#ifndef _RTE_VECT_ARM_H_
#define _RTE_VECT_ARM_H_
-#include "arm_neon.h"
+#include
#ifdef __cplusplus
extern "C" {
#endif
typedef int32x4_t xmm_t;
+typedef int32x4_t __m128i;
#defineXMM_SIZE(sizeof(xmm_t))
#defineXMM_MASK(XMM_SIZE - 1)
@@ -53,6 +54,20 @@ typedef union rte_xmm {
double pd[XMM_SIZE / sizeof(double)];
} __attribute__((aligned(16))) rte_xmm_t;
+/* rte_vect_* abstraction implementation using NEON */
+
+/* loads the __m128i value from address p(does not need to be 16-byte
aligned)*/
+#define rte_vect_loadu_sil128(p) vld1q_s32((const int32_t *)p)
+
+/* sets the 4 signed 32-bit integer values and returns the __m128i variable */
+static inline __m128i __attribute__((always_inline))
+rte_vect_set_epi32(int i3, int i2, int i1, int i0)
+{
+ int32_t data[4] = {i0, i1, i2, i3};
+
+ return vld1q_s32(data);
+}
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/common/include/arch/x86/rte_vect.h
b/lib/librte_eal/common/include/arch/x86/rte_vect.h
index b698797..91c6523 100644
--- a/lib/librte_eal/common/include/arch/x86/rte_vect.h
+++ b/lib/librte_eal/common/include/arch/x86/rte_vect.h
@@ -125,6 +125,14 @@ typedef union rte_ymm {
})
#endif /* (defined(__ICC) && __ICC < 1210) */
+/* rte_vect_* abstraction implementation using SSE */
+
+/* loads the __m128i value from address p(does not need to be 16-byte
aligned)*/
+#define rte_vect_loadu_sil128(p) _mm_loadu_si128(p)
+
+/* sets the 4 signed 32-bit integer values and returns the __m128i variable */
+#define rte_vect_set_epi32(i3, i2, i1, i0) _mm_set_epi32(i3, i2, i1, i0)
+
#ifdef __cplusplus
}
#endif
--
2.1.0
[dpdk-dev] [PATCH 2/3] lpm: add support for NEON
enabled CONFIG_RTE_LIBRTE_LPM, CONFIG_RTE_LIBRTE_TABLE,
CONFIG_RTE_LIBRTE_PIPELINE libraries for arm64.
TABLE, PIPELINE libraries were disabled due to LPM library dependency.
Signed-off-by: Jerin Jacob
---
app/test/test_lpm.c| 10 +-
config/defconfig_arm64-armv8a-linuxapp-gcc | 3 -
lib/librte_lpm/Makefile| 3 +
lib/librte_lpm/rte_lpm.h | 5 +
lib/librte_lpm/rte_lpm_neon.h | 172 +
5 files changed, 185 insertions(+), 8 deletions(-)
create mode 100644 lib/librte_lpm/rte_lpm_neon.h
diff --git a/app/test/test_lpm.c b/app/test/test_lpm.c
index 8b4ded9..207301b 100644
--- a/app/test/test_lpm.c
+++ b/app/test/test_lpm.c
@@ -324,7 +324,7 @@ test7(void)
status = rte_lpm_lookup(lpm, ip, &next_hop_return);
TEST_LPM_ASSERT((status == 0) && (next_hop_return == next_hop_add));
- ipx4 = _mm_set_epi32(ip, ip + 0x100, ip - 0x100, ip);
+ ipx4 = rte_vect_set_epi32(ip, ip + 0x100, ip - 0x100, ip);
rte_lpm_lookupx4(lpm, ipx4, hop, UINT16_MAX);
TEST_LPM_ASSERT(hop[0] == next_hop_add);
TEST_LPM_ASSERT(hop[1] == UINT16_MAX);
@@ -380,7 +380,7 @@ test8(void)
TEST_LPM_ASSERT((status == 0) &&
(next_hop_return == next_hop_add));
- ipx4 = _mm_set_epi32(ip2, ip1, ip2, ip1);
+ ipx4 = rte_vect_set_epi32(ip2, ip1, ip2, ip1);
rte_lpm_lookupx4(lpm, ipx4, hop, UINT16_MAX);
TEST_LPM_ASSERT(hop[0] == UINT16_MAX);
TEST_LPM_ASSERT(hop[1] == next_hop_add);
@@ -408,7 +408,7 @@ test8(void)
status = rte_lpm_lookup(lpm, ip1, &next_hop_return);
TEST_LPM_ASSERT(status == -ENOENT);
- ipx4 = _mm_set_epi32(ip1, ip1, ip2, ip2);
+ ipx4 = rte_vect_set_epi32(ip1, ip1, ip2, ip2);
rte_lpm_lookupx4(lpm, ipx4, hop, UINT16_MAX);
if (depth != 1) {
TEST_LPM_ASSERT(hop[0] == next_hop_add);
@@ -872,7 +872,7 @@ test12(void)
TEST_LPM_ASSERT((status == 0) &&
(next_hop_return == next_hop_add));
- ipx4 = _mm_set_epi32(ip, ip + 1, ip, ip - 1);
+ ipx4 = rte_vect_set_epi32(ip, ip + 1, ip, ip - 1);
rte_lpm_lookupx4(lpm, ipx4, hop, UINT16_MAX);
TEST_LPM_ASSERT(hop[0] == UINT16_MAX);
TEST_LPM_ASSERT(hop[1] == next_hop_add);
@@ -1291,7 +1291,7 @@ perf_test(void)
unsigned k;
__m128i ipx4;
- ipx4 = _mm_loadu_si128((__m128i *)(ip_batch + j));
+ ipx4 = rte_vect_loadu_sil128((__m128i *)(ip_batch + j));
ipx4 = *(__m128i *)(ip_batch + j);
rte_lpm_lookupx4(lpm, ipx4, next_hops, UINT16_MAX);
for (k = 0; k < RTE_DIM(next_hops); k++)
diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc
b/config/defconfig_arm64-armv8a-linuxapp-gcc
index 504f3ed..57f7941 100644
--- a/config/defconfig_arm64-armv8a-linuxapp-gcc
+++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
@@ -51,7 +51,4 @@ CONFIG_RTE_LIBRTE_IVSHMEM=n
CONFIG_RTE_LIBRTE_FM10K_PMD=n
CONFIG_RTE_LIBRTE_I40E_PMD=n
-CONFIG_RTE_LIBRTE_LPM=n
-CONFIG_RTE_LIBRTE_TABLE=n
-CONFIG_RTE_LIBRTE_PIPELINE=n
CONFIG_RTE_SCHED_VECTOR=n
diff --git a/lib/librte_lpm/Makefile b/lib/librte_lpm/Makefile
index 688cfc9..2fd5305 100644
--- a/lib/librte_lpm/Makefile
+++ b/lib/librte_lpm/Makefile
@@ -46,6 +46,9 @@ SRCS-$(CONFIG_RTE_LIBRTE_LPM) := rte_lpm.c rte_lpm6.c
# install this header file
SYMLINK-$(CONFIG_RTE_LIBRTE_LPM)-include := rte_lpm.h rte_lpm6.h
+ifeq ($(CONFIG_RTE_ARCH_ARM64),y)
+SYMLINK-$(CONFIG_RTE_LIBRTE_LPM)-include += rte_lpm_neon.h
+endif
# this lib needs eal
DEPDIRS-$(CONFIG_RTE_LIBRTE_LPM) += lib/librte_eal
diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
index c299ce2..12b75ce 100644
--- a/lib/librte_lpm/rte_lpm.h
+++ b/lib/librte_lpm/rte_lpm.h
@@ -361,6 +361,9 @@ rte_lpm_lookup_bulk_func(const struct rte_lpm *lpm, const
uint32_t * ips,
/* Mask four results. */
#define RTE_LPM_MASKX4_RES UINT64_C(0x00ff00ff00ff00ff)
+#if defined(RTE_ARCH_ARM64)
+#include "rte_lpm_neon.h"
+#else
/**
* Lookup four IP addresses in an LPM table.
*
@@ -473,6 +476,8 @@ rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip,
uint16_t hop[4],
hop[3] = (tbl[3] & RTE_LPM_LOOKUP_SUCCESS) ? (uint8_t)tbl[3] : defv;
}
+#endif
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_lpm/rte_lpm_neon.h b/lib/librte_lpm/rte_lpm_neon.h
new file mode 100644
index 000..6ec4255
--- /dev/null
+++ b/lib/librte_lpm/rte_lpm_neon.h
@@ -0,0 +1,172 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2015 Cavium Networks. All rights reserved.
+ * All rights reserved.
+ *
+ * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * All righ
[dpdk-dev] [PATCH 3/3] maintainers: claim responsibility for arm64 specific files of hash and lpm
Signed-off-by: Jerin Jacob --- MAINTAINERS | 3 +++ 1 file changed, 3 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4478862..dc8f80a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -130,6 +130,9 @@ ARM v8 M: Jerin Jacob F: lib/librte_eal/common/include/arch/arm/*_64.h F: lib/librte_acl/acl_run_neon.* +F: lib/librte_lpm/rte_lpm_neon.h +F: lib/librte_hash/rte_crc_arm64.h +F: lib/librte_hash/rte_cmp_arm64.h EZchip TILE-Gx M: Zhigang Lu -- 2.1.0
[dpdk-dev] [PATCH] rte_sched: drop deprecation notice for RED statistics
The RED statistics are now added. Signed-off-by: Stephen Hemminger --- doc/guides/rel_notes/deprecation.rst | 3 --- 1 file changed, 3 deletions(-) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 1c7ab01..deed679 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -12,9 +12,6 @@ Deprecation Notices ibadcrc, ibadlen, imcasts, fdirmatch, fdirmiss, tx_pause_xon, rx_pause_xon, tx_pause_xoff, rx_pause_xoff -* The scheduler statistics structure will change to allow keeping track of - RED actions. - * librte_pipeline: The prototype for the pipeline input port, output port and table action handlers will be updated: the pipeline parameter will be added, the packets mask parameter will be -- 2.1.4
[dpdk-dev] DPDK Community Call - ARM Support
This is just a reminder that this call is on tomorrow, at 15:00 GMT. I'll be travelling, but Jim St Leger has agreed to host the call. The agenda is: ARMv7 & v8 ports: - Summary of what's been submitted for 2.2 and what the remaining gaps are (Dave Hunt) - Discussion on plans for further contributions in this area External Memory Manager: - Summary of our plans for DPDK 2.3 (Venky Venkatesan) - Do others plan to do work in this area? Other DPDK/ARM plans: - Does anybody else have plans for ARM-related work in DPDK that they can share? The link for the online meeting is: https://global.gotomeeting.com/join/535221101. Further details on the meeting time in other timezones, and dial-in numbers for various countries are included below. Tim > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'Driscoll, Tim > Sent: Thursday, November 19, 2015 11:20 AM > To: Bob Monkman; dev at dpdk.org > Subject: Re: [dpdk-dev] DPDK Community Call - ARM Support > > Thanks for following up on this Bob. It's great to see this level of > engagement from the ARM ecosystem. In order to facilitate this, we'll > move our call out by a week. New details for the meeting are: > > When: > Tue, Dec 1, 2015 15:00 - 16:00 GMT > Tue, Dec 1, 2015 07:00 - 08:00 PST > Tue, Dec 1, 2015 10:00 - 11:00 EST > Tue, Dec 1, 2015 16:00 - 17:00 PST > > Meeting Details: > You can join from your computer, tablet or smartphone: > https://global.gotomeeting.com/join/535221101 > > You can also dial in using your phone. > > Access Code: 535-221-101 > > Phone numbers: > United States: +1 (224) 501-3217 > Australia: +61 2 9087 3605 > Austria: +43 7 2088 1403 > Belgium: +32 (0) 28 93 7019 > Canada: +1 (647) 497-9351 > Denmark: +45 69 91 88 64 > Finland: +358 (0) 942 41 5781 > France: +33 (0) 182 880 458 > Germany: +49 (0) 692 5736 7210 > Ireland +353 (0) 14 845 979 > Italy: +39 0 553 98 95 67 > Netherlands: +31 (0) 208 080 381 > New Zealand: +64 4 974 7214 > Norway: +47 21 03 58 98 > Spain: +34 955 32 0845 > Sweden: +46 (0) 853 527 836 > Switzerland: +41 (0) 435 0167 09 > United Kingdom: +44 (0) 330 221 0086 > > > Tim > > > -Original Message- > > From: Bob Monkman [mailto:Bob.Monkman at arm.com] > > Sent: Wednesday, November 18, 2015 7:27 PM > > To: O'Driscoll, Tim; dev at dpdk.org > > Subject: RE: DPDK Community Call - ARM Support > > > > Tim, et al, > > Thanks for this call to the ARM community to convene to > discuss > > what support is out there in ARM ecosystem. I am responsible for > > networking segment software strategy within ARM and, as some of your > > colleagues already know, I am coordinating collaborative work on DPDK > > for ARM with multiple members of our ARM ecosystem. > > > > My concern on this first discussion is that I, and other key > > stakeholders from engineering management will be out all week for the > US > > Thanksgiving holiday. I suspect other key ARM stakeholder reps who may > > want to join in this conversation may be in the same boat. Would the > > group here be willing to consider same day and time the following > week? > > Tuesday Dec 1? > > > > We would greatly appreciate and I think you will have a better > > chance of critical mass of the right people. > > Regards, > > Bob > > > > Robert (Bob) Monkman > > Enterprise Segment Marketing Manager > > 150 Rose Orchard Way > > San Jose, Ca 95134 > > M: +1.510.676.5490 > > > > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'Driscoll, Tim > > Sent: Tuesday, November 17, 2015 9:09 AM > > To: dev at dpdk.org > > Subject: [dpdk-dev] DPDK Community Call - ARM Support > > > > There's been a lot of activity on the mailing list recently on DPDK > > support for ARM. It's great to see the project being enhanced to > embrace > > a new architecture. > > > > We have seen some duplication of efforts on this, so we think it would > > make a good topic for a community call. This will give everybody a > > chance to share their plans so we can be clear on who's doing what and > > make sure that we avoid overlaps. > > > > We'll host a community call on this next Tuesday (24th Nov) at 15:00- > > 16:00 GMT. Details on the proposed agenda, the time in a couple of > other > > timezones, and how to join the online meeting are included below. > > > > > > Agenda: > > ARMv7 & v8 ports: > > - Summary of what's been submitted for 2.2 and what the remaining gaps > > are (Dave Hunt) > > - Discussion on plans for further contributions in this area > > > > External Memory Manager: > > - Summary of our plans for DPDK 2.3 (Venky Venkatesan) > > - Do others plan to do work in this area? > > > > Other DPDK/ARM plans: > > - Does anybody else have plans for ARM-related work in DPDK that they > > can share? > > > > > > When: > > Tue, Nov 24, 2015 15:00 - 16:00 GMT > > Tue, Nov 24, 2015 07:00 - 08:00 PST > > Tue, Nov 24, 2015 10:00 - 11:00 EST > > Tue, Nov 24, 2015 16:00 - 17:00 PST > > > > >
[dpdk-dev] 2.3 Roadmap
As we're nearing the completion of the 2.2 release, I'd like to start a discussion on plans for 2.3. To kick this off, below are the features that we're hoping to submit for this release. If others are prepared to contribute their plans, then we could build a complete view of the release which Thomas can maintain on the dpdk.org roadmap page, and make sure we're not duplicating work. IPsec Sample Application: A sample application will be created which will show how DPDK and the new cryptodev API can be used to implement IPsec. Use of the cryptodev API will allow either hardware or software encryption to be used. IKE will not be implemented so the SA/SP DBs will be statically configured. Cryptodev Support for SNOW 3G: The cryptodev API, and the hardware and software crypto PMDs that it supports, will be enhanced to support the SNOW 3G cipher. External Mempool Manager: SoCs and some software applications that use DPDK have their own memory allocation capabilities. This feature will allow DPDK to work with an external mempool manager. Packet Framework (Edge Router Use Case): - Further performance tuning for the vPE use case. - Support for load balancing within a pipeline. - Support for CPU utilization measurements within a pipeline. - Improvements for the functional pipelines, tables and ports. Ethdev Enhancements: Merge parts of the Packet Framework ports library into ethdev so they can be used without the Packet Framework. The initial focus is to add support for buffered TX to ethdev. Live Migration: The main infrastructure to support live migration of VMs was implemented over the last few DPDK releases via the Link Bonding and PCI Hot Plug features. This feature will involve further investigation, prototyping and enhancements to improve live migration support in DPDK. Tcpdump Support: Support for tcpdump will be added to DPDK. This will improve usability and debugging of DPDK applications. Increase Next Hops for LPM (IPv4): The number of next hops for IPv4 LPM is currently limited to 256. This will be extended to allow a greater number of next hops. Fm10k Enhancements: FTAG based forwarding, and performance tuning Support Intel Resource Director Technology: A library will be added to DPDK to support the following Intel CPU technologies: - CAT - Cache Allocation Technology (LLC aka L3) - CDP - Code Data Prioritization (extension of CAT) - CMT - Cache Monitoring Technology (LLC) - MBM - Memory Bandwidth Monitoring, to local and remote RAM These technologies are currently available via cgroups and perf, but this feature will provide closer integration with DPDK and a sample application showing how they can be used. I40e Enhancements: - Flow Director input set Alignment - Ethertype configuration for QinQ support - Flow Director Support for Tunnels (QinQ, GRE/NVGRE, VXLAN) - Flow Director Support for IP Proto and IP TOS - VEB switching - Floating VEB - IPGRE Support - Set VF MAC address - Rework PCIe extended tag enabling by using DPDK interfaces Virtio/Vhost Enhancements: - Virtio 1.0 support - Vhost software TSO - Vhost/virtio performance tuning Container Enhancements: - Virtio for containers - Hugetlbfs mount point size - Cgroup resource awareness - Enable short-lived DPDK applications Generic Tunneling API: - Implement virtual flow device framework - Implement generic virtual device management APIs, including the following callback functions: - flow_ethdev_start/stop/configure/close/info_get - ethdev_rx/tx_queue_setup/release - flow_ethdev_tunnel_configure/setup/destroy - flow_ethdev_tunnel_pkt_decap/encap - Implement flow device PMD drive APIs - rte_eth_flow_dev_create/remove/ others - Integrate VXLAN protocol (including VXLAN decap/encap optimization) into this framework only on i40e. Tim
[dpdk-dev] [PATCH] librte_port: fix mbuf allocation in source port
Fixes the mbuf allocation not initialized problem. This problem will cause
the mbufs not be able to freed back to mempool by rte_pktmbuf_free().
The problem was introduced by commit "Packet Framework librte_port: Source
/Sink ports" (commit id ef3403fb6f9a3c4b730d2e4fbe7ddc0291ffa992)
Signed-off-by: Fan Zhang
Acked-by: Cristian Dumitrescu
---
lib/librte_port/rte_port_source_sink.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/lib/librte_port/rte_port_source_sink.c
b/lib/librte_port/rte_port_source_sink.c
index 234ab18..5e10144 100644
--- a/lib/librte_port/rte_port_source_sink.c
+++ b/lib/librte_port/rte_port_source_sink.c
@@ -105,10 +105,16 @@ static int
rte_port_source_rx(void *port, struct rte_mbuf **pkts, uint32_t n_pkts)
{
struct rte_port_source *p = (struct rte_port_source *) port;
+ uint32_t i;
if (rte_mempool_get_bulk(p->mempool, (void **) pkts, n_pkts) != 0)
return 0;
+ for (i = 0; i < n_pkts; i++) {
+ rte_mbuf_refcnt_set(pkts[i], 1);
+ rte_pktmbuf_reset(pkts[i]);
+ }
+
RTE_PORT_SOURCE_STATS_PKTS_IN_ADD(p, n_pkts);
return n_pkts;
--
2.5.0
[dpdk-dev] [PATCH] librte_port: fix sink port statistics
Fixes the sink port statistics incomplete problem. The problem was
introduced by commit "Packet Framework librte_port: Source/Sink ports"
(commit id ef3403fb6f9a3c4b730d2e4fbe7ddc0291ffa992)
Signed-off-by: Fan Zhang
Acked-by: Cristian Dumitrescu
---
lib/librte_port/rte_port_source_sink.c | 63 +++---
1 file changed, 59 insertions(+), 4 deletions(-)
diff --git a/lib/librte_port/rte_port_source_sink.c
b/lib/librte_port/rte_port_source_sink.c
index 234ab18..ab362e1 100644
--- a/lib/librte_port/rte_port_source_sink.c
+++ b/lib/librte_port/rte_port_source_sink.c
@@ -133,28 +133,64 @@ rte_port_source_stats_read(void *port,
/*
* Port SINK
*/
+#ifdef RTE_PORT_STATS_COLLECT
+
+#define RTE_PORT_SINK_STATS_PKTS_IN_ADD(port, val) \
+ (port->stats.n_pkts_in += val)
+#define RTE_PORT_SINK_STATS_PKTS_DROP_ADD(port, val) \
+ (port->stats.n_pkts_drop += val)
+
+#else
+
+#define RTE_PORT_SINK_STATS_PKTS_IN_ADD(port, val)
+#define RTE_PORT_SINK_STATS_PKTS_DROP_ADD(port, val)
+
+#endif
+
+struct rte_port_sink {
+ struct rte_port_out_stats stats;
+};
+
static void *
-rte_port_sink_create(__rte_unused void *params, __rte_unused int socket_id)
+rte_port_sink_create(__rte_unused void *params, int socket_id)
{
- return (void *) 1;
+ struct rte_port_sink *port;
+
+ /* Memory allocation */
+ port = rte_zmalloc_socket("PORT", sizeof(*port),
+ RTE_CACHE_LINE_SIZE, socket_id);
+ if (port == NULL) {
+ RTE_LOG(ERR, PORT, "%s: Failed to allocate port\n", __func__);
+ return NULL;
+ }
+
+ return port;
}
static int
-rte_port_sink_tx(__rte_unused void *port, struct rte_mbuf *pkt)
+rte_port_sink_tx(void *port, struct rte_mbuf *pkt)
{
+ __rte_unused struct rte_port_sink *p = (struct rte_port_sink *) port;
+
+ RTE_PORT_SINK_STATS_PKTS_IN_ADD(p, 1);
rte_pktmbuf_free(pkt);
+ RTE_PORT_SINK_STATS_PKTS_DROP_ADD(p, 1);
return 0;
}
static int
-rte_port_sink_tx_bulk(__rte_unused void *port, struct rte_mbuf **pkts,
+rte_port_sink_tx_bulk(void *port, struct rte_mbuf **pkts,
uint64_t pkts_mask)
{
+ __rte_unused struct rte_port_sink *p = (struct rte_port_sink *) port;
+
if ((pkts_mask & (pkts_mask + 1)) == 0) {
uint64_t n_pkts = __builtin_popcountll(pkts_mask);
uint32_t i;
+ RTE_PORT_SINK_STATS_PKTS_IN_ADD(p, n_pkts);
+ RTE_PORT_SINK_STATS_PKTS_DROP_ADD(p, n_pkts);
for (i = 0; i < n_pkts; i++) {
struct rte_mbuf *pkt = pkts[i];
@@ -166,6 +202,8 @@ rte_port_sink_tx_bulk(__rte_unused void *port, struct
rte_mbuf **pkts,
uint64_t pkt_mask = 1LLU << pkt_index;
struct rte_mbuf *pkt = pkts[pkt_index];
+ RTE_PORT_SINK_STATS_PKTS_IN_ADD(p, 1);
+ RTE_PORT_SINK_STATS_PKTS_DROP_ADD(p, 1);
rte_pktmbuf_free(pkt);
pkts_mask &= ~pkt_mask;
}
@@ -174,6 +212,22 @@ rte_port_sink_tx_bulk(__rte_unused void *port, struct
rte_mbuf **pkts,
return 0;
}
+static int
+rte_port_sink_stats_read(void *port, struct rte_port_out_stats *stats,
+ int clear)
+{
+ struct rte_port_sink *p =
+ (struct rte_port_sink *) port;
+
+ if (stats != NULL)
+ memcpy(stats, &p->stats, sizeof(p->stats));
+
+ if (clear)
+ memset(&p->stats, 0, sizeof(p->stats));
+
+ return 0;
+}
+
/*
* Summary of port operations
*/
@@ -190,4 +244,5 @@ struct rte_port_out_ops rte_port_sink_ops = {
.f_tx = rte_port_sink_tx,
.f_tx_bulk = rte_port_sink_tx_bulk,
.f_flush = NULL,
+ .f_stats = rte_port_sink_stats_read,
};
--
2.5.0
[dpdk-dev] 2.3 Roadmap
It looks very ambitious :) Thank you Intel for pushing forward! 2015-11-30 20:50, O'Driscoll, Tim: > As we're nearing the completion of the 2.2 release, I'd like to start a > discussion on plans for 2.3. To kick this off, below are the features that > we're hoping to submit for this release. > > If others are prepared to contribute their plans, then we could build a > complete view of the release which Thomas can maintain on the dpdk.org > roadmap page, and make sure we're not duplicating work. > > > IPsec Sample Application: A sample application will be created which will > show how DPDK and the new cryptodev API can be used to implement IPsec. Use > of the cryptodev API will allow either hardware or software encryption to be > used. IKE will not be implemented so the SA/SP DBs will be statically > configured. > > Cryptodev Support for SNOW 3G: The cryptodev API, and the hardware and > software crypto PMDs that it supports, will be enhanced to support the SNOW > 3G cipher. > > External Mempool Manager: SoCs and some software applications that use DPDK > have their own memory allocation capabilities. This feature will allow DPDK > to work with an external mempool manager. > > Packet Framework (Edge Router Use Case): > - Further performance tuning for the vPE use case. > - Support for load balancing within a pipeline. > - Support for CPU utilization measurements within a pipeline. > - Improvements for the functional pipelines, tables and ports. > > Ethdev Enhancements: Merge parts of the Packet Framework ports library into > ethdev so they can be used without the Packet Framework. The initial focus is > to add support for buffered TX to ethdev. > > Live Migration: The main infrastructure to support live migration of VMs was > implemented over the last few DPDK releases via the Link Bonding and PCI Hot > Plug features. This feature will involve further investigation, prototyping > and enhancements to improve live migration support in DPDK. > > Tcpdump Support: Support for tcpdump will be added to DPDK. This will improve > usability and debugging of DPDK applications. > > Increase Next Hops for LPM (IPv4): The number of next hops for IPv4 LPM is > currently limited to 256. This will be extended to allow a greater number of > next hops. > > Fm10k Enhancements: FTAG based forwarding, and performance tuning > > Support Intel Resource Director Technology: A library will be added to DPDK > to support the following Intel CPU technologies: > - CAT - Cache Allocation Technology (LLC aka L3) > - CDP - Code Data Prioritization (extension of CAT) > - CMT - Cache Monitoring Technology (LLC) > - MBM - Memory Bandwidth Monitoring, to local and remote RAM > These technologies are currently available via cgroups and perf, but this > feature will provide closer integration with DPDK and a sample application > showing how they can be used. > > I40e Enhancements: > - Flow Director input set Alignment > - Ethertype configuration for QinQ support > - Flow Director Support for Tunnels (QinQ, GRE/NVGRE, VXLAN) > - Flow Director Support for IP Proto and IP TOS > - VEB switching > - Floating VEB > - IPGRE Support > - Set VF MAC address > - Rework PCIe extended tag enabling by using DPDK interfaces > > Virtio/Vhost Enhancements: > - Virtio 1.0 support > - Vhost software TSO > - Vhost/virtio performance tuning > > Container Enhancements: > - Virtio for containers > - Hugetlbfs mount point size > - Cgroup resource awareness > - Enable short-lived DPDK applications > > Generic Tunneling API: > - Implement virtual flow device framework > - Implement generic virtual device management APIs, including the following > callback functions: > - flow_ethdev_start/stop/configure/close/info_get > - ethdev_rx/tx_queue_setup/release > - flow_ethdev_tunnel_configure/setup/destroy > - flow_ethdev_tunnel_pkt_decap/encap > - Implement flow device PMD drive APIs > - rte_eth_flow_dev_create/remove/ others > - Integrate VXLAN protocol (including VXLAN decap/encap optimization) into > this framework only on i40e. > > > Tim
[dpdk-dev] 2.3 Roadmap
Hi Tim, Just curious about one item on the list: On 11/30/2015 03:50 PM, O'Driscoll, Tim wrote: > IPsec Sample Application: A sample application will be created which will > show how DPDK and the new cryptodev API can be used to implement IPsec. Use > of the cryptodev API will allow either hardware or software encryption to be > used. IKE will not be implemented so the SA/SP DBs will be statically > configured. Do you anticipate this application living in the dpdk repo, or in a separate tree? Thanks, Dave. -- Dave Neary - NFV/SDN Community Strategy Open Source and Standards, Red Hat - http://community.redhat.com Ph: +1-978-399-2182 / Cell: +1-978-799-3338
[dpdk-dev] 2.3 Roadmap
Hi, CAT And CDP technologies look very intriguing Could you elaborate a little on those? -HK From: dev on behalf of O'Driscoll, Tim Sent: Monday, November 30, 2015 9:50:58 PM To: dev at dpdk.org Subject: [dpdk-dev] 2.3 Roadmap As we're nearing the completion of the 2.2 release, I'd like to start a discussion on plans for 2.3. To kick this off, below are the features that we're hoping to submit for this release. If others are prepared to contribute their plans, then we could build a complete view of the release which Thomas can maintain on the dpdk.org roadmap page, and make sure we're not duplicating work. IPsec Sample Application: A sample application will be created which will show how DPDK and the new cryptodev API can be used to implement IPsec. Use of the cryptodev API will allow either hardware or software encryption to be used. IKE will not be implemented so the SA/SP DBs will be statically configured. Cryptodev Support for SNOW 3G: The cryptodev API, and the hardware and software crypto PMDs that it supports, will be enhanced to support the SNOW 3G cipher. External Mempool Manager: SoCs and some software applications that use DPDK have their own memory allocation capabilities. This feature will allow DPDK to work with an external mempool manager. Packet Framework (Edge Router Use Case): - Further performance tuning for the vPE use case. - Support for load balancing within a pipeline. - Support for CPU utilization measurements within a pipeline. - Improvements for the functional pipelines, tables and ports. Ethdev Enhancements: Merge parts of the Packet Framework ports library into ethdev so they can be used without the Packet Framework. The initial focus is to add support for buffered TX to ethdev. Live Migration: The main infrastructure to support live migration of VMs was implemented over the last few DPDK releases via the Link Bonding and PCI Hot Plug features. This feature will involve further investigation, prototyping and enhancements to improve live migration support in DPDK. Tcpdump Support: Support for tcpdump will be added to DPDK. This will improve usability and debugging of DPDK applications. Increase Next Hops for LPM (IPv4): The number of next hops for IPv4 LPM is currently limited to 256. This will be extended to allow a greater number of next hops. Fm10k Enhancements: FTAG based forwarding, and performance tuning Support Intel Resource Director Technology: A library will be added to DPDK to support the following Intel CPU technologies: - CAT - Cache Allocation Technology (LLC aka L3) - CDP - Code Data Prioritization (extension of CAT) - CMT - Cache Monitoring Technology (LLC) - MBM - Memory Bandwidth Monitoring, to local and remote RAM These technologies are currently available via cgroups and perf, but this feature will provide closer integration with DPDK and a sample application showing how they can be used. I40e Enhancements: - Flow Director input set Alignment - Ethertype configuration for QinQ support - Flow Director Support for Tunnels (QinQ, GRE/NVGRE, VXLAN) - Flow Director Support for IP Proto and IP TOS - VEB switching - Floating VEB - IPGRE Support - Set VF MAC address - Rework PCIe extended tag enabling by using DPDK interfaces Virtio/Vhost Enhancements: - Virtio 1.0 support - Vhost software TSO - Vhost/virtio performance tuning Container Enhancements: - Virtio for containers - Hugetlbfs mount point size - Cgroup resource awareness - Enable short-lived DPDK applications Generic Tunneling API: - Implement virtual flow device framework - Implement generic virtual device management APIs, including the following callback functions: - flow_ethdev_start/stop/configure/close/info_get - ethdev_rx/tx_queue_setup/release - flow_ethdev_tunnel_configure/setup/destroy - flow_ethdev_tunnel_pkt_decap/encap - Implement flow device PMD drive APIs - rte_eth_flow_dev_create/remove/ others - Integrate VXLAN protocol (including VXLAN decap/encap optimization) into this framework only on i40e. Tim
[dpdk-dev] 2.3 Roadmap
Hi Tim, On Mon, Nov 30, 2015 at 3:50 PM, O'Driscoll, Tim wrote: > Tcpdump Support: Support for tcpdump will be added to DPDK. This will improve > usability and debugging of DPDK applications. I'm curious about the proposed tcpdump support. Is there a concrete plan for this, or is that still being looked into? Sandvine is interested in contributing to this effort. Anything we can do to help? Thanks, Kyle
