[dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework

[dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework

[Declan Doherty]

I've been trying out using google test as a possible replacement for our unit
test framework and have put to together this series of patches with help from
Anatoly as RFC to get peoples thoughts on migrating to google test.

To facilitate google test this rfc patch set contains build system changes to
allow C++ to built within the DPDK framework, this intended for unit test code
only, and to support google test which is a C++ framework. Don't worry, I'm not
advocating making DPDK a C++ project :) 

A new EAL option to allow the user to silence logging to stdout while still
logging to syslog. This was to facilitate a eclipse plugin I was using which
parses googe test output, so it is not strictly necessary.

A example application which uses the C++ build changes.

And finally a google test application which some mempool tests ported from the
current test app to give a feel of what google test is like to use for testing
C. 

Some of the major advantages of google test that I see over continuing to use the
current test include giving a consist feel to all tests, a powerful test
execution framework which allow individual test suites or tests to be specified
from the command line, support for a standard xunit output which can be integrated
into a continuous build systems, and a very powerful mocking library
which allows much more control over testing failure conditions.

Have a look at the patch set keeping in mind that this isn't intended to be
production code, I imagine that build systems changes for C++ would require some
refinement etc

Regards
Declan


Anatoly Burakov (2):
  mk: Add support for C++ compilation
  examples: add c++ example application

Declan Doherty (2):
  eal: add command line option to log output to stdout
  app/test-gtest: example google test application

 app/Makefile                               |   1 +
 app/test-gtest/Makefile                    |  67 +++++++
 app/test-gtest/main.cpp                    |  20 ++
 app/test-gtest/test_mempool.cpp            | 281 +++++++++++++++++++++++++++++
 config/common_base                         |   5 +
 examples/Makefile                          |   1 +
 examples/helloworld-cpp/Makefile           |  51 ++++++
 examples/helloworld-cpp/c_code.c           |   5 +
 examples/helloworld-cpp/c_header.h         |   6 +
 examples/helloworld-cpp/cpp_code.cpp       |  89 +++++++++
 lib/librte_eal/common/eal_common_log.c     |  14 ++
 lib/librte_eal/common/eal_common_options.c |   8 +
 lib/librte_eal/common/eal_options.h        |   2 +
 lib/librte_eal/common/include/rte_log.h    |  15 ++
 lib/librte_eal/linuxapp/eal/eal.c          |   1 +
 lib/librte_eal/linuxapp/eal/eal_log.c      |  23 ++-
 mk/internal/rte.compile-pre.mk             |  52 +++++-
 mk/target/generic/rte.vars.mk              |   3 +
 mk/toolchain/clang/rte.vars.mk             |  14 +-
 mk/toolchain/gcc/rte.vars.mk               |  14 +-
 mk/toolchain/icc/rte.vars.mk               |  10 +-
 21 files changed, 660 insertions(+), 22 deletions(-)
 create mode 100644 app/test-gtest/Makefile
 create mode 100644 app/test-gtest/main.cpp
 create mode 100644 app/test-gtest/test_mempool.cpp
 create mode 100644 examples/helloworld-cpp/Makefile
 create mode 100644 examples/helloworld-cpp/c_code.c
 create mode 100644 examples/helloworld-cpp/c_header.h
 create mode 100644 examples/helloworld-cpp/cpp_code.cpp

-- 
2.5.5

[dpdk-dev] [RFC 1/4] mk: Add support for C++ compilation

[Declan Doherty]

From: Anatoly Burakov <anatoly.burakov@intel.com>

Adding support for compiling C++ files as part of the build system

Signed-off-by: Declan Doherty <declan.doherty@intel.com>
---
 mk/internal/rte.compile-pre.mk | 52 ++++++++++++++++++++++++++++++++++++++----
 mk/target/generic/rte.vars.mk  |  3 +++
 mk/toolchain/clang/rte.vars.mk | 14 +++++++++---
 mk/toolchain/gcc/rte.vars.mk   | 14 +++++++++---
 mk/toolchain/icc/rte.vars.mk   | 10 +++++---
 5 files changed, 80 insertions(+), 13 deletions(-)

diff --git a/mk/internal/rte.compile-pre.mk b/mk/internal/rte.compile-pre.mk
index f740179..2342942 100644
--- a/mk/internal/rte.compile-pre.mk
+++ b/mk/internal/rte.compile-pre.mk
@@ -32,12 +32,12 @@
 #
 # Common to rte.lib.mk, rte.app.mk, rte.obj.mk
 #
-
 SRCS-all := $(SRCS-y) $(SRCS-n) $(SRCS-)
 
 # convert source to obj file
 src2obj = $(strip $(patsubst %.c,%.o,\
-	$(patsubst %.S,%_s.o,$(1))))
+	$(patsubst %.S,%_s.o,\
+	$(patsubst %.cpp,%_cpp.o,$(1)))))
 
 # add a dot in front of the file name
 dotfile = $(strip $(foreach f,$(1),\
@@ -46,12 +46,14 @@ dotfile = $(strip $(foreach f,$(1),\
 # convert source/obj files into dot-dep filename (does not
 # include .S files)
 src2dep = $(strip $(call dotfile,$(patsubst %.c,%.o.d, \
-		$(patsubst %.S,,$(1)))))
+		$(patsubst %.cpp,%_cpp.o.d, \
+		$(patsubst %.S,,$(1))))))
 obj2dep = $(strip $(call dotfile,$(patsubst %.o,%.o.d,$(1))))
 
 # convert source/obj files into dot-cmd filename
 src2cmd = $(strip $(call dotfile,$(patsubst %.c,%.o.cmd, \
-		$(patsubst %.S,%_s.o.cmd,$(1)))))
+		$(patsubst %.cpp,%_cpp.o.cmd, \
+		$(patsubst %.S,%_s.o.cmd,$(1))))))
 obj2cmd = $(strip $(call dotfile,$(patsubst %.o,%.o.cmd,$(1))))
 
 OBJS-y := $(call src2obj,$(SRCS-y))
@@ -186,3 +188,45 @@ S_TO_O_DO = @set -e; \
 		$(depfile_missing),\
 		$(depfile_newer)),\
 		$(S_TO_O_DO))
+
+
+# command to compile a .cpp file to generate an object
+ifeq ($(USE_HOST),1)
+CXX_TO_O = $(HOSTCXX) -Wp,-MD,$(call obj2dep,$(@)).tmp $(HOST_CXXFLAGS) \
+	$(CXXFLAGS_$(@)) $(HOST_EXTRA_CXXFLAGS) -o $@ -c $<
+CXX_TO_O_STR = $(subst ','\'',$(CXX_TO_O)) #'# fix syntax highlight
+CXX_TO_O_DISP = $(if $(V),"$(CXX_TO_O_STR)","  HOSTCXX $(@)")
+else
+CXX_TO_O = $(CXX) -Wp,-MD,$(call obj2dep,$(@)).tmp $(CXXFLAGS) \
+	$(CXXFLAGS_$(@)) $(EXTRA_CXXFLAGS) -o $@ -c $<
+CXX_TO_O_STR = $(subst ','\'',$(CXX_TO_O)) #'# fix syntax highlight
+CXX_TO_O_DISP = $(if $(V),"$(CXX_TO_O_STR)","  CXX $(@)")
+endif
+CXX_TO_O_CMD = 'cmd_$@ = $(CXX_TO_O_STR)'
+CXX_TO_O_DO = @set -e; \
+	echo $(CXX_TO_O_DISP); \
+	$(CXX_TO_O) && \
+	echo $(CXX_TO_O_CMD) > $(call obj2cmd,$(@)) && \
+	sed 's,'$@':,dep_'$@' =,' $(call obj2dep,$(@)).tmp > $(call obj2dep,$(@)) && \
+	rm -f $(call obj2dep,$(@)).tmp
+
+#
+# Compile .cpp file if needed
+# Note: dep_$$@ is from the .d file and DEP_$$@ can be specified by
+# user (by default it is empty)
+#
+.SECONDEXPANSION:
+%_cpp.o: %.cpp $$(wildcard $$(dep_$$@)) $$(DEP_$$(@)) FORCE
+	@[ -d $(dir $@) ] || mkdir -p $(dir $@)
+	$(if $(D),\
+		@echo -n "$< -> $@ " ; \
+		echo -n "file_missing=$(call boolean,$(file_missing)) " ; \
+		echo -n "cmdline_changed=$(call boolean,$(call cmdline_changed,$(CXX_TO_O))) " ; \
+		echo -n "depfile_missing=$(call boolean,$(depfile_missing)) " ; \
+		echo "depfile_newer=$(call boolean,$(depfile_newer))")
+	$(if $(or \
+		$(file_missing),\
+		$(call cmdline_changed,$(CXX_TO_O)),\
+		$(depfile_missing),\
+		$(depfile_newer)),\
+		$(CXX_TO_O_DO))
\ No newline at end of file
diff --git a/mk/target/generic/rte.vars.mk b/mk/target/generic/rte.vars.mk
index 75a616a..128d4e2 100644
--- a/mk/target/generic/rte.vars.mk
+++ b/mk/target/generic/rte.vars.mk
@@ -138,7 +138,10 @@ endif
 LDFLAGS += -L$(RTE_SDK_BIN)/lib
 endif
 
+CXXFLAGS := $(CFLAGS)
+
 export CFLAGS
+export CXXFLAGS
 export LDFLAGS
 
 endif
diff --git a/mk/toolchain/clang/rte.vars.mk b/mk/toolchain/clang/rte.vars.mk
index 7749b99..2a7105e 100644
--- a/mk/toolchain/clang/rte.vars.mk
+++ b/mk/toolchain/clang/rte.vars.mk
@@ -32,8 +32,9 @@
 #
 # toolchain:
 #
-#   - define CC, LD, AR, AS, ... (overriden by cmdline value)
+#   - define CC, CXX, LD, AR, AS, ... (overriden by cmdline value)
 #   - define TOOLCHAIN_CFLAGS variable (overriden by cmdline value)
+#   - define TOOLCHAIN_CXXFLAGS variable (overriden by cmdline value)
 #   - define TOOLCHAIN_LDFLAGS variable (overriden by cmdline value)
 #   - define TOOLCHAIN_ASFLAGS variable (overriden by cmdline value)
 #
@@ -41,6 +42,7 @@
 CC        = $(CROSS)clang
 KERNELCC  = $(CROSS)gcc
 CPP       = $(CROSS)cpp
+CXX       = $(CROSS)clang++
 # for now, we don't use as but nasm.
 # AS      = $(CROSS)as
 AS        = nasm
@@ -57,10 +59,16 @@ HOSTCC    = $(CC)
 else
 HOSTCC    = clang
 endif
+ifeq ("$(origin CXX)", "command line")
+HOSTCXX    = $(CXX)
+else
+HOSTCXX    = clang++
+endif
 HOSTAS    = as
 
 TOOLCHAIN_ASFLAGS =
 TOOLCHAIN_CFLAGS =
+TOOLCHAIN_CXXFLAGS =
 TOOLCHAIN_LDFLAGS =
 
 WERROR_FLAGS := -W -Wall -Wstrict-prototypes -Wmissing-prototypes
@@ -79,5 +87,5 @@ include $(RTE_SDK)/mk/toolchain/$(RTE_TOOLCHAIN)/rte.toolchain-compat.mk
 # workaround clang bug with warning "missing field initializer" for "= {0}"
 WERROR_FLAGS += -Wno-missing-field-initializers
 
-export CC AS AR LD OBJCOPY OBJDUMP STRIP READELF
-export TOOLCHAIN_CFLAGS TOOLCHAIN_LDFLAGS TOOLCHAIN_ASFLAGS
+export CC CXX AS AR LD OBJCOPY OBJDUMP STRIP READELF
+export TOOLCHAIN_CFLAGS TOOLCHAIN_CXXFLAGS TOOLCHAIN_LDFLAGS TOOLCHAIN_ASFLAGS
diff --git a/mk/toolchain/gcc/rte.vars.mk b/mk/toolchain/gcc/rte.vars.mk
index ff70f3d..1961f6c 100644
--- a/mk/toolchain/gcc/rte.vars.mk
+++ b/mk/toolchain/gcc/rte.vars.mk
@@ -32,8 +32,9 @@
 #
 # toolchain:
 #
-#   - define CC, LD, AR, AS, ... (overriden by cmdline value)
+#   - define CC, CXX, LD, AR, AS, ... (overriden by cmdline value)
 #   - define TOOLCHAIN_CFLAGS variable (overriden by cmdline value)
+#   - define TOOLCHAIN_CXXFLAGS variable (overriden by cmdline value)
 #   - define TOOLCHAIN_LDFLAGS variable (overriden by cmdline value)
 #   - define TOOLCHAIN_ASFLAGS variable (overriden by cmdline value)
 #
@@ -41,6 +42,7 @@
 CC        = $(CROSS)gcc
 KERNELCC  = $(CROSS)gcc
 CPP       = $(CROSS)cpp
+CXX       = $(CROSS)g++
 # for now, we don't use as but nasm.
 # AS      = $(CROSS)as
 AS        = nasm
@@ -57,10 +59,16 @@ HOSTCC    = $(CC)
 else
 HOSTCC    = gcc
 endif
+ifeq ("$(origin CXX)", "command line")
+HOSTCXX    = $(CXX)
+else
+HOSTCXX    = g++
+endif
 HOSTAS    = as
 
 TOOLCHAIN_ASFLAGS =
 TOOLCHAIN_CFLAGS =
+TOOLCHAIN_CXXFLAGS =
 TOOLCHAIN_LDFLAGS =
 
 ifeq ($(CONFIG_RTE_LIBRTE_GCOV),y)
@@ -99,5 +107,5 @@ ifeq ($(shell test $(GCC_VERSION) -lt 47 && echo 1), 1)
 WERROR_FLAGS += -Wno-uninitialized
 endif
 
-export CC AS AR LD OBJCOPY OBJDUMP STRIP READELF
-export TOOLCHAIN_CFLAGS TOOLCHAIN_LDFLAGS TOOLCHAIN_ASFLAGS
+export CC CXX AS AR LD OBJCOPY OBJDUMP STRIP READELF
+export TOOLCHAIN_CFLAGS TOOLCHAIN_CXXFLAGS TOOLCHAIN_LDFLAGS TOOLCHAIN_ASFLAGS
diff --git a/mk/toolchain/icc/rte.vars.mk b/mk/toolchain/icc/rte.vars.mk
index ba69f1f..e9d6721 100644
--- a/mk/toolchain/icc/rte.vars.mk
+++ b/mk/toolchain/icc/rte.vars.mk
@@ -32,8 +32,9 @@
 #
 # toolchain:
 #
-#   - define CC, LD, AR, AS, ... (overriden by cmdline value)
+#   - define CC, CXX, LD, AR, AS, ... (overriden by cmdline value)
 #   - define TOOLCHAIN_CFLAGS variable (overriden by cmdline value)
+#   - define TOOLCHAIN_CXXFLAGS variable (overriden by cmdline value)
 #   - define TOOLCHAIN_LDFLAGS variable (overriden by cmdline value)
 #   - define TOOLCHAIN_ASFLAGS variable (overriden by cmdline value)
 #
@@ -42,6 +43,7 @@
 # x86->x86 compiler
 
 CC        = icc
+CXX       = icc
 KERNELCC  = gcc
 CPP       = cpp
 AS        = nasm
@@ -57,9 +59,11 @@ HOSTCC    = icc
 else
 HOSTCC    = gcc
 endif
+HOSTCXX   = icc
 HOSTAS    = as
 
 TOOLCHAIN_CFLAGS =
+TOOLCHAIN_CXXFLAGS =
 TOOLCHAIN_LDFLAGS =
 TOOLCHAIN_ASFLAGS =
 
@@ -83,5 +87,5 @@ ifeq ($(shell test $(ICC_MAJOR_VERSION) -ge 14 && echo 1), 1)
 	TOOLCHAIN_CFLAGS += -no-inline-max-size -no-inline-max-total-size
 endif
 
-export CC AS AR LD OBJCOPY OBJDUMP STRIP READELF
-export TOOLCHAIN_CFLAGS TOOLCHAIN_LDFLAGS TOOLCHAIN_ASFLAGS
+export CC CXX AS AR LD OBJCOPY OBJDUMP STRIP READELF
+export TOOLCHAIN_CFLAGS TOOLCHAIN_CXXFLAGS TOOLCHAIN_LDFLAGS TOOLCHAIN_ASFLAGS
-- 
2.5.5

[dpdk-dev] [RFC 2/4] examples: add c++ example application

[Declan Doherty]

From: Anatoly Burakov <anatoly.burakov@intel.com>

Example application for C++ compilation

Signed-off-by: Declan Doherty <declan.doherty@intel.com>
---
 examples/Makefile                    |  1 +
 examples/helloworld-cpp/Makefile     | 51 +++++++++++++++++++++
 examples/helloworld-cpp/c_code.c     |  5 ++
 examples/helloworld-cpp/c_header.h   |  6 +++
 examples/helloworld-cpp/cpp_code.cpp | 89 ++++++++++++++++++++++++++++++++++++
 5 files changed, 152 insertions(+)
 create mode 100644 examples/helloworld-cpp/Makefile
 create mode 100644 examples/helloworld-cpp/c_code.c
 create mode 100644 examples/helloworld-cpp/c_header.h
 create mode 100644 examples/helloworld-cpp/cpp_code.cpp

diff --git a/examples/Makefile b/examples/Makefile
index 18b41b9..cb81c6c 100644
--- a/examples/Makefile
+++ b/examples/Makefile
@@ -46,6 +46,7 @@ endif
 DIRS-y += ethtool
 DIRS-y += exception_path
 DIRS-y += helloworld
+DIRS-y += helloworld-cpp
 DIRS-$(CONFIG_RTE_LIBRTE_PIPELINE) += ip_pipeline
 ifeq ($(CONFIG_RTE_LIBRTE_LPM),y)
 DIRS-$(CONFIG_RTE_IP_FRAG) += ip_reassembly
diff --git a/examples/helloworld-cpp/Makefile b/examples/helloworld-cpp/Makefile
new file mode 100644
index 0000000..f8f281c
--- /dev/null
+++ b/examples/helloworld-cpp/Makefile
@@ -0,0 +1,51 @@
+#   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.
+
+ifeq ($(RTE_SDK),)
+$(error "Please define RTE_SDK environment variable")
+endif
+
+# Default target, can be overriden by command line or environment
+RTE_TARGET ?= x86_64-native-linuxapp-gcc
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+# binary name
+APP = helloworld-cpp
+
+# all source are stored in SRCS-y
+SRCS-y := c_code.c cpp_code.cpp
+
+CFLAGS += -O3
+CFLAGS += $(WERROR_FLAGS)
+LDFLAGS += -lstdc++
+
+include $(RTE_SDK)/mk/rte.extapp.mk
diff --git a/examples/helloworld-cpp/c_code.c b/examples/helloworld-cpp/c_code.c
new file mode 100644
index 0000000..d349a3b
--- /dev/null
+++ b/examples/helloworld-cpp/c_code.c
@@ -0,0 +1,5 @@
+#include "c_header.h"
+
+int func(void) {
+	return 100500;
+}
diff --git a/examples/helloworld-cpp/c_header.h b/examples/helloworld-cpp/c_header.h
new file mode 100644
index 0000000..3668b60
--- /dev/null
+++ b/examples/helloworld-cpp/c_header.h
@@ -0,0 +1,6 @@
+#ifndef HEADER_H
+#define HEADER_H
+
+int func(void);
+
+#endif
diff --git a/examples/helloworld-cpp/cpp_code.cpp b/examples/helloworld-cpp/cpp_code.cpp
new file mode 100644
index 0000000..6919048
--- /dev/null
+++ b/examples/helloworld-cpp/cpp_code.cpp
@@ -0,0 +1,89 @@
+/*-
+ *   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 <stdio.h>
+#include <string.h>
+#include <stdint.h>
+#include <errno.h>
+#include <sys/queue.h>
+
+#include <rte_memory.h>
+#include <rte_memzone.h>
+#include <rte_launch.h>
+#include <rte_eal.h>
+#include <rte_per_lcore.h>
+#include <rte_lcore.h>
+#include <rte_debug.h>
+
+#include <iostream>
+
+extern "C" {
+#include "c_header.h"
+};
+
+using namespace std;
+
+static int
+lcore_hello(__attribute__((unused)) void *arg)
+{
+	unsigned lcore_id;
+	lcore_id = rte_lcore_id();
+	printf("hello from core %u\n", lcore_id);
+	return 0;
+}
+
+int
+main(int argc, char **argv)
+{
+	int ret;
+	unsigned lcore_id;
+
+	cout << "Hellow world from C++" << endl;
+
+	cout << "Output from C code: " << func() << endl;
+
+	ret = rte_eal_init(argc, argv);
+	if (ret < 0)
+		rte_panic("Cannot init EAL\n");
+
+	/* call lcore_hello() on every slave lcore */
+	RTE_LCORE_FOREACH_SLAVE(lcore_id) {
+		rte_eal_remote_launch(lcore_hello, NULL, lcore_id);
+	}
+
+	/* call it on master lcore too */
+	lcore_hello(NULL);
+
+	rte_eal_mp_wait_lcore();
+	return 0;
+}
-- 
2.5.5

[dpdk-dev] [RFC 3/4] eal: add command line option to log output to stdout

[Declan Doherty]

Adds new command line options which allows the user to stop
application echoing log output to stdout, logs are still
written to syslog.

Signed-off-by: Declan Doherty <declan.doherty@intel.com>
---
 lib/librte_eal/common/eal_common_log.c     | 14 ++++++++++++++
 lib/librte_eal/common/eal_common_options.c |  8 ++++++++
 lib/librte_eal/common/eal_options.h        |  2 ++
 lib/librte_eal/common/include/rte_log.h    | 15 +++++++++++++++
 lib/librte_eal/linuxapp/eal/eal.c          |  1 +
 lib/librte_eal/linuxapp/eal/eal_log.c      | 23 ++++++++++++++---------
 6 files changed, 54 insertions(+), 9 deletions(-)

diff --git a/lib/librte_eal/common/eal_common_log.c b/lib/librte_eal/common/eal_common_log.c
index 7916c78..8319823 100644
--- a/lib/librte_eal/common/eal_common_log.c
+++ b/lib/librte_eal/common/eal_common_log.c
@@ -45,6 +45,7 @@
 struct rte_logs rte_logs = {
 	.type = ~0,
 	.level = RTE_LOG_DEBUG,
+	.silent = 1,
 	.file = NULL,
 };
 
@@ -102,6 +103,18 @@ rte_get_log_level(void)
 	return rte_logs.level;
 }
 
+void
+rte_log_silence_stdout(void)
+{
+	rte_logs.silent = 0;
+}
+
+int
+rte_log_stdout(void)
+{
+	return rte_logs.silent;
+}
+
 /* Set global log type */
 void
 rte_set_log_type(uint32_t type, int enable)
@@ -125,6 +138,7 @@ int rte_log_cur_msg_loglevel(void)
 	return RTE_PER_LCORE(log_cur_msg).loglevel;
 }
 
+
 /* get the current logtype for the message beeing processed */
 int rte_log_cur_msg_logtype(void)
 {
diff --git a/lib/librte_eal/common/eal_common_options.c b/lib/librte_eal/common/eal_common_options.c
index 1a1bab3..186cfeb 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -69,6 +69,7 @@ eal_short_options[] =
 	"r:" /* memory ranks */
 	"v"  /* version */
 	"w:" /* pci-whitelist */
+	"s"  /* silence log output to stdout */
 	;
 
 const struct option
@@ -95,6 +96,7 @@ eal_long_options[] = {
 	{OPT_VFIO_INTR,         1, NULL, OPT_VFIO_INTR_NUM        },
 	{OPT_VMWARE_TSC_MAP,    0, NULL, OPT_VMWARE_TSC_MAP_NUM   },
 	{OPT_XEN_DOM0,          0, NULL, OPT_XEN_DOM0_NUM         },
+	{OPT_SILENT_STDOUT,     0, NULL, OPT_SILENT_STDOUT_NUM    },
 	{0,                     0, NULL, 0                        }
 };
 
@@ -842,6 +844,10 @@ eal_parse_common_option(int opt, const char *optarg,
 		RTE_LOG(CRIT, EAL, "RTE Version: '%s'\n", rte_version());
 		break;
 
+	case OPT_SILENT_STDOUT_NUM:
+		rte_log_silence_stdout();
+		break;
+
 	/* long options */
 	case OPT_HUGE_UNLINK_NUM:
 		conf->hugepage_unlink = 1;
@@ -906,6 +912,7 @@ eal_parse_common_option(int opt, const char *optarg,
 		conf->log_level = log;
 		break;
 	}
+
 	case OPT_LCORES_NUM:
 		if (eal_parse_lcores(optarg) < 0) {
 			RTE_LOG(ERR, EAL, "invalid parameter for --"
@@ -1028,6 +1035,7 @@ eal_common_usage(void)
 	       "  --"OPT_PROC_TYPE"         Type of this process (primary|secondary|auto)\n"
 	       "  --"OPT_SYSLOG"            Set syslog facility\n"
 	       "  --"OPT_LOG_LEVEL"         Set default log level\n"
+	       "  -s, --"OPT_SILENT_STDOUT" Silent mode, supress output to STDOUT\n"
 	       "  -v                  Display version information on startup\n"
 	       "  -h, --help          This help\n"
 	       "\nEAL options for DEBUG use only:\n"
diff --git a/lib/librte_eal/common/eal_options.h b/lib/librte_eal/common/eal_options.h
index a881c62..ce6547c 100644
--- a/lib/librte_eal/common/eal_options.h
+++ b/lib/librte_eal/common/eal_options.h
@@ -41,6 +41,8 @@ enum {
 	OPT_PCI_BLACKLIST_NUM   = 'b',
 #define OPT_PCI_WHITELIST     "pci-whitelist"
 	OPT_PCI_WHITELIST_NUM   = 'w',
+#define OPT_SILENT_STDOUT     "log-stdout-silent"
+	OPT_SILENT_STDOUT_NUM   = 's',
 
 	/* first long only option value must be >= 256, so that we won't
 	 * conflict with short options */
diff --git a/lib/librte_eal/common/include/rte_log.h b/lib/librte_eal/common/include/rte_log.h
index b1add04..74acb91 100644
--- a/lib/librte_eal/common/include/rte_log.h
+++ b/lib/librte_eal/common/include/rte_log.h
@@ -56,6 +56,7 @@ extern "C" {
 struct rte_logs {
 	uint32_t type;  /**< Bitfield with enabled logs. */
 	uint32_t level; /**< Log level. */
+	uint32_t silent:1; /**< Silent mode - Don't print to STDOUT */
 	FILE *file;     /**< Pointer to current FILE* for logs. */
 };
 
@@ -181,6 +182,20 @@ int rte_log_cur_msg_loglevel(void);
 int rte_log_cur_msg_logtype(void);
 
 /**
+ * Silence output to stdout by logging facilities
+ */
+void rte_log_silence_stdout(void);
+
+/**
+ * Check if echoing log output to stdout is enabled.
+ *
+ * @return
+ * - Returns 1 if echoing to stdout is enabled
+ * - Returns 0 if logging is in silent mode
+ */
+int rte_log_stdout(void);
+
+/**
  * @deprecated
  * Enable or disable the history (enabled by default)
  *
diff --git a/lib/librte_eal/linuxapp/eal/eal.c b/lib/librte_eal/linuxapp/eal/eal.c
index 3fb2188..8f8ed42 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -748,6 +748,7 @@ rte_eal_init(int argc, char **argv)
 
 	thread_id = pthread_self();
 
+
 	if (rte_eal_log_early_init() < 0)
 		rte_panic("Cannot init early logs\n");
 
diff --git a/lib/librte_eal/linuxapp/eal/eal_log.c b/lib/librte_eal/linuxapp/eal/eal_log.c
index d391100..5387e5a 100644
--- a/lib/librte_eal/linuxapp/eal/eal_log.c
+++ b/lib/librte_eal/linuxapp/eal/eal_log.c
@@ -56,12 +56,14 @@ static ssize_t
 console_log_write(__attribute__((unused)) void *c, const char *buf, size_t size)
 {
 	char copybuf[BUFSIZ + 1];
-	ssize_t ret;
+	ssize_t ret = 0;
 	uint32_t loglevel;
-
+ 
 	/* write on stdout */
-	ret = fwrite(buf, 1, size, stdout);
-	fflush(stdout);
+	if (rte_log_stdout()) {
+		ret = fwrite(buf, 1, size, stdout);
+		fflush(stdout);
+	}
 
 	/* truncate message if too big (should not happen) */
 	if (size > BUFSIZ)
@@ -111,11 +113,14 @@ rte_eal_log_init(const char *id, int facility)
 static ssize_t
 early_log_write(__attribute__((unused)) void *c, const char *buf, size_t size)
 {
-	ssize_t ret;
-	ret = fwrite(buf, size, 1, stdout);
-	fflush(stdout);
-	if (ret == 0)
-		return -1;
+	ssize_t ret = 0;
+
+	if (rte_log_stdout()) {
+		ret = fwrite(buf, size, 1, stdout);
+		fflush(stdout);
+		if (ret == 0)
+			return -1;
+	}
 	return ret;
 }
 
-- 
2.5.5

[dpdk-dev] [RFC 4/4] app/test-gtest: example google test application

[Declan Doherty]

Adds a new application to demonstrate how google test could
be used as a new unit test framework.

To compile both ${GTEST_DIR} and ${GMOCK_DIR} the install paths to google
test and google mock directories respectively must be defined/exported.

Signed-off-by: Declan Doherty <declan.doherty@intel.com>
---
 app/Makefile                    |   1 +
 app/test-gtest/Makefile         |  67 ++++++++++
 app/test-gtest/main.cpp         |  20 +++
 app/test-gtest/test_mempool.cpp | 281 ++++++++++++++++++++++++++++++++++++++++
 config/common_base              |   5 +
 5 files changed, 374 insertions(+)
 create mode 100644 app/test-gtest/Makefile
 create mode 100644 app/test-gtest/main.cpp
 create mode 100644 app/test-gtest/test_mempool.cpp

diff --git a/app/Makefile b/app/Makefile
index 30ec292..71cf31e 100644
--- a/app/Makefile
+++ b/app/Makefile
@@ -38,5 +38,6 @@ DIRS-$(CONFIG_RTE_TEST_PMD) += test-pmd
 DIRS-$(CONFIG_RTE_LIBRTE_CMDLINE) += cmdline_test
 DIRS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) += proc_info
 DIRS-$(CONFIG_RTE_LIBRTE_PDUMP) += pdump
+DIRS-$(CONFIG_RTE_TEST_GTEST) += test-gtest
 
 include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/app/test-gtest/Makefile b/app/test-gtest/Makefile
new file mode 100644
index 0000000..66dbe15
--- /dev/null
+++ b/app/test-gtest/Makefile
@@ -0,0 +1,67 @@
+#   BSD LICENSE
+#   BSD LICENSE
+#
+#   Copyright(c) 2016 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.
+
+
+ifneq ($(MAKECMDGOALS),clean)
+ifeq ($(GTEST_DIR),)
+$(error "Please define GTEST_DIR environment variable")
+endif
+
+ifeq ($(GMOCK_DIR),)
+$(error "Please define GMOCK_DIR environment variable")
+endif
+endif
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+# binary name
+APP = test-gtest
+
+# all source are stored in SRCS-y
+SRCS-y := main.cpp
+SRCS-y += test_mempool.cpp
+
+CFLAGS += -O0
+CFLAGS += $(WERROR_FLAGS)
+
+CXXFLAGS += -std=c++11
+CXXFLAGS += -I$(GTEST_DIR)/include 
+CXXFLAGS += -I$(GMOCK_DIR)/include
+
+LDFLAGS += -lstdc++
+LDFLAGS += -L$(GMOCK_DIR) -lgmock
+
+# this application needs libraries first
+DEPDIRS-y += lib drivers
+
+include $(RTE_SDK)/mk/rte.app.mk
+
diff --git a/app/test-gtest/main.cpp b/app/test-gtest/main.cpp
new file mode 100644
index 0000000..a221823
--- /dev/null
+++ b/app/test-gtest/main.cpp
@@ -0,0 +1,20 @@
+#include <gtest/gtest.h>
+#include <gmock/gmock.h>
+
+#include <stdio.h>
+
+#include <rte_common.h>
+#include <rte_eal.h>
+
+int main(int argc, char *argv[])
+{
+	/* Initialise DPDK EAL */
+	int ret = rte_eal_init(argc, argv);
+	if (ret < 0)
+		rte_exit(EXIT_FAILURE, "Invalid EAL arguments\n");
+	argc -= ret;
+	argv += ret;
+
+	testing::InitGoogleMock(&argc, argv);
+	return RUN_ALL_TESTS();
+}	
diff --git a/app/test-gtest/test_mempool.cpp b/app/test-gtest/test_mempool.cpp
new file mode 100644
index 0000000..4c3f7e2
--- /dev/null
+++ b/app/test-gtest/test_mempool.cpp
@@ -0,0 +1,281 @@
+#include <gtest/gtest.h>
+#include <gmock/gmock.h>
+
+#include <stdio.h>
+
+#include <rte_common.h>
+#include <rte_eal.h>
+#include <rte_log.h>
+#include <rte_mempool.h>
+
+class MemoryPool : public ::testing::Test {
+
+protected:
+
+	virtual void SetUp() {
+		mp = NULL;
+		mempool_elements = (rte_lcore_count() * (lcore_cache_size +
+				RTE_MEMPOOL_CACHE_MAX_SIZE) -1);
+	}
+
+	virtual void TearDown() {
+		if (mp)
+			rte_mempool_free(mp);
+
+	}
+
+	/*
+	 * save the object number in the first 4 bytes of object data. All
+	 * other bytes are set to 0.
+	 */
+	static void
+	obj_initializer_fn(struct rte_mempool *mp, void *arg __rte_unused,
+			void *obj, unsigned i)
+	{
+		uint32_t *objnum = (uint32_t *)obj;
+
+		memset(obj, 0, mp->elt_size);
+		*objnum = i;
+	}
+
+	struct rte_mempool *mp;
+
+	static const unsigned element_size = 2048;
+	static const uint32_t lcore_cache_size = 16;
+
+	unsigned mempool_elements;
+};
+
+TEST_F(MemoryPool, CreateWithNoCache)
+{
+	mp = rte_mempool_create("test_nocache", mempool_elements, element_size,
+			0, 0, NULL, NULL, obj_initializer_fn, NULL,
+			SOCKET_ID_ANY, 0);
+
+	ASSERT_NE(mp, (void *)NULL);
+
+	EXPECT_EQ(mp, rte_mempool_lookup("test_nocache"));
+	EXPECT_EQ(rte_mempool_avail_count(mp), mempool_elements);
+}
+
+TEST_F(MemoryPool, CreateWithCache)
+{
+	mp = rte_mempool_create("test_cache", mempool_elements, element_size,
+			RTE_MEMPOOL_CACHE_MAX_SIZE, 0, NULL, NULL,
+			obj_initializer_fn, NULL, SOCKET_ID_ANY, 0);
+
+	ASSERT_NE(mp, (void *)NULL);
+
+	EXPECT_EQ(mp, rte_mempool_lookup("test_cache"));
+	EXPECT_EQ(rte_mempool_avail_count(mp), mempool_elements);
+}
+
+TEST_F(MemoryPool, ExceedMaxCacheSize)
+{
+	mp = rte_mempool_create("test_exceed_max_cache_sz",
+			mempool_elements, element_size,
+			RTE_MEMPOOL_CACHE_MAX_SIZE + 1, 0, NULL, NULL,
+			obj_initializer_fn, NULL, SOCKET_ID_ANY, 0);
+
+	ASSERT_EQ(mp, (void *)NULL);
+}
+
+TEST_F(MemoryPool, MempoolNameCollosion) {
+	mp = rte_mempool_create("test_name_collosion", mempool_elements,
+			element_size, RTE_MEMPOOL_CACHE_MAX_SIZE, 0, NULL, NULL,
+			obj_initializer_fn, NULL, SOCKET_ID_ANY, 0);
+
+	ASSERT_NE(mp, (void *)NULL);
+
+	ASSERT_EQ(rte_mempool_create("test_name_collosion", mempool_elements,
+			element_size, RTE_MEMPOOL_CACHE_MAX_SIZE, 0, NULL, NULL,
+			obj_initializer_fn, NULL, SOCKET_ID_ANY, 0),
+			(struct rte_mempool *)NULL);
+}
+
+TEST_F(MemoryPool, ExternalMemorySize) {
+	size_t sz;
+	ssize_t usz;
+
+	uint32_t obj_size = rte_mempool_calc_obj_size(element_size, 0, NULL);
+
+	sz = rte_mempool_xmem_size(mempool_elements, obj_size,
+			MEMPOOL_PG_SHIFT_MAX);
+
+	usz = rte_mempool_xmem_usage(NULL, mempool_elements, obj_size, 0, 1,
+			MEMPOOL_PG_SHIFT_MAX);
+
+	EXPECT_EQ(sz, (size_t)usz);
+}
+
+
+class MempoolMock {
+public:
+
+	MOCK_METHOD2(MempoolInitializerMockFn,
+			void(struct rte_mempool *, void *));
+
+	MOCK_METHOD4(MempoolObjInitializerMockFn,
+			void(struct rte_mempool *, void *arg, void *, unsigned));
+
+	static MempoolMock *obj;
+
+	static void mempool_initializer_fn(struct rte_mempool *mp, void * arg)
+	{
+		obj->MempoolInitializerMockFn(mp, arg);
+	}
+
+	static void mempool_obj_initializer_fn(struct rte_mempool *mp,
+			void *arg, void *m_obj, unsigned i)
+	{
+		obj->MempoolObjInitializerMockFn(mp, arg, m_obj, i);
+	}
+};
+
+
+MempoolMock * MempoolMock::obj;
+
+TEST_F(MemoryPool, MempoolInitialization)
+{
+	MempoolMock mock;
+	MempoolMock::obj = &mock;
+
+
+	EXPECT_CALL(mock, MempoolInitializerMockFn(::testing::_, ::testing::_))
+		.Times(1);
+
+	EXPECT_CALL(mock, MempoolObjInitializerMockFn(
+			::testing::_, ::testing::_, ::testing::_, ::testing::_))
+			.Times(mempool_elements);
+
+	mp = rte_mempool_create("test_nocache", mempool_elements,
+			element_size, 0, 0,
+			MempoolMock::mempool_initializer_fn, NULL,
+			MempoolMock::mempool_obj_initializer_fn, NULL,
+			SOCKET_ID_ANY, 0);
+	ASSERT_NE(mp, (void *)NULL);
+
+	EXPECT_EQ(rte_mempool_full(mp), 1);
+}
+
+
+class MemoryPoolWithNoCache : public MemoryPool {
+protected :
+	virtual void SetUp() {
+		mempool_elements = (rte_lcore_count() * (lcore_cache_size +
+				RTE_MEMPOOL_CACHE_MAX_SIZE) -1);
+
+		objs = (void **)malloc(mempool_elements * sizeof(void *));
+
+		mp = rte_mempool_create("test_nocache", mempool_elements,
+				element_size, 0, 0, NULL, NULL,
+				obj_initializer_fn, NULL, SOCKET_ID_ANY, 0);
+		ASSERT_NE(mp, (void *)NULL);
+
+		EXPECT_EQ(rte_mempool_full(mp), 1);
+
+	}
+
+	virtual void TearDown() {
+		if (mp)
+			rte_mempool_free(mp);
+
+		if (objs)
+			free(objs);
+
+	}
+
+	void **objs;
+	int i;
+};
+
+TEST_F(MemoryPoolWithNoCache, GetOneObjectPutOneObject)
+{
+	/* Get an object for mempool */
+	ASSERT_EQ(rte_mempool_get(mp, &objs[0]), 0);
+
+	/* Verify object count in mempool */
+	EXPECT_EQ(rte_mempool_avail_count(mp), mempool_elements -1);
+
+	/* Verify physical address of an object */
+
+#ifndef RTE_EXEC_ENV_BSDAPP
+	/* rte_mem_virt2phy() not supported on BSD */
+	EXPECT_EQ(rte_mempool_virt2phy(mp, objs[0]), rte_mem_virt2phy(objs[0]));
+#endif
+
+	/* put the object back */
+	rte_mempool_put(mp, objs[0]);
+
+	EXPECT_EQ(rte_mempool_avail_count(mp), mempool_elements);
+}
+
+TEST_F(MemoryPoolWithNoCache, GetAllObjectsPutAllObjects)
+{
+	/* Get all objects from mempool */
+	for (i = 0; i < mempool_elements; i++) {
+		EXPECT_EQ(rte_mempool_get(mp, &objs[i]), 0);
+		/* Verify physical address of an object */
+#ifndef RTE_EXEC_ENV_BSDAPP
+		EXPECT_EQ(rte_mempool_virt2phy(mp, objs[i]),
+				rte_mem_virt2phy(objs[i]));
+#endif
+	}
+
+	/* Verify object count in mempool */
+	EXPECT_EQ(rte_mempool_avail_count(mp), 0);
+
+
+	/* Put the objects back */
+	for (i = 0; i < mempool_elements; i++) {
+		rte_mempool_put(mp, objs[i]);
+	}
+
+	EXPECT_EQ(rte_mempool_avail_count(mp), mempool_elements);
+}
+
+TEST_F(MemoryPoolWithNoCache, GetOjectFromEmptyMempool)
+{
+	void *err_obj = NULL;
+
+	for (i = 0; i < mempool_elements; i++)
+		EXPECT_EQ(rte_mempool_get(mp, &objs[i]), 0);
+
+	EXPECT_EQ(rte_mempool_empty(mp), 1);
+
+	EXPECT_LT(rte_mempool_get(mp, &err_obj), 0);
+	EXPECT_EQ(err_obj, (void *)NULL);
+
+	for (i = 0; i < mempool_elements; i++)
+		rte_mempool_put(mp, objs[i]);
+
+	EXPECT_EQ(rte_mempool_full(mp), 1);
+	// printf("test_mempool_basic_ex the mempool should be full\n");
+}
+
+
+
+class MemoryPoolSingleProducerSingleConsumer : public MemoryPool {
+protected:
+	virtual void SetUp() {
+		lcore_id = rte_lcore_id();
+
+		mempool_elements = (rte_lcore_count() * (lcore_cache_size +
+				RTE_MEMPOOL_CACHE_MAX_SIZE) -1);
+
+		mp = rte_mempool_create("single_producer_consumer",
+				mempool_elements, element_size, 0, 0,
+				NULL, NULL,
+				obj_initializer_fn, NULL,
+				SOCKET_ID_ANY,
+				MEMPOOL_F_NO_CACHE_ALIGN |
+				MEMPOOL_F_SP_PUT |
+				MEMPOOL_F_SC_GET);
+
+		ASSERT_NE(mp, (void *)NULL);
+
+		EXPECT_EQ(rte_mempool_full(mp), 1);
+	}
+
+	unsigned lcore_id, lcore_next;
+};
diff --git a/config/common_base b/config/common_base
index 7830535..6ef4de6 100644
--- a/config/common_base
+++ b/config/common_base
@@ -579,6 +579,11 @@ CONFIG_RTE_APP_TEST=y
 CONFIG_RTE_APP_TEST_RESOURCE_TAR=n
 
 #
+# Compile the google test unit tests
+#
+CONFIG_RTE_TEST_GTEST=y
+
+#
 # Compile the PMD test application
 #
 CONFIG_RTE_TEST_PMD=y
-- 
2.5.5

Re: [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework

[Thomas Monjalon]

2016-08-02 21:37, Declan Doherty:
> I've been trying out using google test as a possible replacement for our unit
> test framework and have put to together this series of patches with help from
> Anatoly as RFC to get peoples thoughts on migrating to google test.

Thanks for exploring new possibilities.

> To facilitate google test this rfc patch set contains build system changes to
> allow C++ to built within the DPDK framework, this intended for unit test code
> only, and to support google test which is a C++ framework. Don't worry, I'm not
> advocating making DPDK a C++ project :) 

You are not advocating but the unit test must be written in C++.
I don't think it is a good idea to force people to write and maintain the tests
in a different language than the code it tests.

> Some of the major advantages of google test that I see over continuing to use the
> current test include giving a consist feel to all tests, a powerful test
> execution framework which allow individual test suites or tests to be specified
> from the command line, support for a standard xunit output which can be integrated
> into a continuous build systems, and a very powerful mocking library
> which allows much more control over testing failure conditions.

It would be interesting to better describe in details what is missing currently
and what such a framework can bring.
(I agree there is a huge room for improvements on unit tests)

Re: [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework

[Remy Horton]

On 02/08/2016 22:52, Thomas Monjalon wrote:
> 2016-08-02 21:37, Declan Doherty:
[..]
> You are not advocating but the unit test must be written in C++.
> I don't think it is a good idea to force people to write and maintain the tests
> in a different language than the code it tests.

In principle I agree, but in practice I don't see any alternative. All 
the purely C-based frameworks I've (independently of Declan) tried don't 
have the same flexibility as the C++ ones.


> It would be interesting to better describe in details what is missing currently
> and what such a framework can bring.
> (I agree there is a huge room for improvements on unit tests)

 From my own perspective, mocking of functions is the main thing that is 
missing. When testing KeepAlive this allowed me to reroute rte_malloc() 
calls to the OS malloc() rather than having to startup/teardown the 
hugepage subsystem.

..Remy

Re: [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework

[Doherty, Declan]

> -----Original Message-----
...
> You are not advocating but the unit test must be written in C++.
> I don't think it is a good idea to force people to write and maintain the tests
> in a different language than the code it tests.

I know where you are coming from on this point, and I general would agree if
it were not for the advantages you get from C++ test framework. Having worked with
multiple C and C++ frameworks, I've found that one of the biggest advantages of the
C++ frameworks is the amount of boilerplate code they can save you from writing. Also
nearly all of C frameworks I've used make use macros to the point that they look more like
objective C than C. In general I feel that even if the test code is written in C++ the code itself
should be simple enough that someone with even a passing knowledge of C++ could easily
understand the intent of the test code. 

> > Some of the major advantages of google test that I see over continuing to use
> the
> > current test include giving a consist feel to all tests, a powerful test
> > execution framework which allow individual test suites or tests to be specified
> > from the command line, support for a standard xunit output which can be
> integrated
> > into a continuous build systems, and a very powerful mocking library
> > which allows much more control over testing failure conditions.
> 
> It would be interesting to better describe in details what is missing currently
> and what such a framework can bring.
> (I agree there is a huge room for improvements on unit tests)

Some of the things I've come across include:
No standard output format to integrated with continuous regression systems
No ability to specify specific unit tests or groups of tests to run from the command line
No standard set of test assertions used across the test suites.
No standard setup and teardown functions across test suites, state from previous test
suite can break current
Requirement to use a python script to orchestrate test runs.
No support for mocking functionality.

I know that none of the above couldn't be fixed in our current test application, but I would 
question if it is effort worthwhile when we take an off the shelf framework, which does all 
those things and a whole lot more, which has been test and used in a huge variety of
projects. 

I certainly willing to look at other frameworks both C and C++ but I yet to find a C framework
which come close to the usability and flexibility of the popular C++ ones.

Re: [dpdk-dev] [RFC 3/4] eal: add command line option to log output to stdout

[Neil Horman]

On Tue, Aug 02, 2016 at 09:37:48PM +0100, Declan Doherty wrote:
> Adds new command line options which allows the user to stop
> application echoing log output to stdout, logs are still
> written to syslog.
> 
> Signed-off-by: Declan Doherty <declan.doherty@intel.com>
> ---
>  lib/librte_eal/common/eal_common_log.c     | 14 ++++++++++++++
>  lib/librte_eal/common/eal_common_options.c |  8 ++++++++
>  lib/librte_eal/common/eal_options.h        |  2 ++
>  lib/librte_eal/common/include/rte_log.h    | 15 +++++++++++++++
>  lib/librte_eal/linuxapp/eal/eal.c          |  1 +
>  lib/librte_eal/linuxapp/eal/eal_log.c      | 23 ++++++++++++++---------
>  6 files changed, 54 insertions(+), 9 deletions(-)
> 
> diff --git a/lib/librte_eal/common/eal_common_log.c b/lib/librte_eal/common/eal_common_log.c
> index 7916c78..8319823 100644
> --- a/lib/librte_eal/common/eal_common_log.c
> +++ b/lib/librte_eal/common/eal_common_log.c
> @@ -45,6 +45,7 @@
>  struct rte_logs rte_logs = {
>  	.type = ~0,
>  	.level = RTE_LOG_DEBUG,
> +	.silent = 1,
>  	.file = NULL,
>  };
>  
> @@ -102,6 +103,18 @@ rte_get_log_level(void)
>  	return rte_logs.level;
>  }
>  
> +void
> +rte_log_silence_stdout(void)
> +{
> +	rte_logs.silent = 0;
> +}
> +
> +int
> +rte_log_stdout(void)
> +{
> +	return rte_logs.silent;
Maybe you want to return !rte_logs.silent?  That way the sense of the actual
variable makes human readable sense.  i.e. currently rte_logs.silent is set to 1
if you want to print to stdout, which seems backwards

Neil

Re: [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework

[Neil Horman]

On Tue, Aug 02, 2016 at 11:52:24PM +0200, Thomas Monjalon wrote:
> 2016-08-02 21:37, Declan Doherty:
> > I've been trying out using google test as a possible replacement for our unit
> > test framework and have put to together this series of patches with help from
> > Anatoly as RFC to get peoples thoughts on migrating to google test.
> 
> Thanks for exploring new possibilities.
> 
> > To facilitate google test this rfc patch set contains build system changes to
> > allow C++ to built within the DPDK framework, this intended for unit test code
> > only, and to support google test which is a C++ framework. Don't worry, I'm not
> > advocating making DPDK a C++ project :) 
> 
> You are not advocating but the unit test must be written in C++.
> I don't think it is a good idea to force people to write and maintain the tests
> in a different language than the code it tests.
> 

I agree, there are lots of xunit based integration tests that are available as
pure C frameworks.  Jenkins might also be a good candidate here.

> > Some of the major advantages of google test that I see over continuing to use the
> > current test include giving a consist feel to all tests, a powerful test
> > execution framework which allow individual test suites or tests to be specified
> > from the command line, support for a standard xunit output which can be integrated
> > into a continuous build systems, and a very powerful mocking library
> > which allows much more control over testing failure conditions.
> 
> It would be interesting to better describe in details what is missing currently
> and what such a framework can bring.
> (I agree there is a huge room for improvements on unit tests)
> 

I agree that a test framework gives a consistent look and feel to all tests, but
it seems to me that would be the case with any framework worth its salt.  While
I'm not opposed to google test per-se, the fact that it requires C++ to build
makes me wonder if there isn't a better option available.

Neil

Re: [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework

[Neil Horman]

On Wed, Aug 03, 2016 at 09:57:39AM +0000, Doherty, Declan wrote:
> 
> 
> > -----Original Message-----
> ...
> > You are not advocating but the unit test must be written in C++.
> > I don't think it is a good idea to force people to write and maintain the tests
> > in a different language than the code it tests.
> 
> I know where you are coming from on this point, and I general would agree if
> it were not for the advantages you get from C++ test framework. Having worked with
> multiple C and C++ frameworks, I've found that one of the biggest advantages of the
> C++ frameworks is the amount of boilerplate code they can save you from writing. Also
> nearly all of C frameworks I've used make use macros to the point that they look more like
> objective C than C. In general I feel that even if the test code is written in C++ the code itself
> should be simple enough that someone with even a passing knowledge of C++ could easily
> understand the intent of the test code. 
> 
> > > Some of the major advantages of google test that I see over continuing to use
> > the
> > > current test include giving a consist feel to all tests, a powerful test
> > > execution framework which allow individual test suites or tests to be specified
> > > from the command line, support for a standard xunit output which can be
> > integrated
> > > into a continuous build systems, and a very powerful mocking library
> > > which allows much more control over testing failure conditions.
> > 
> > It would be interesting to better describe in details what is missing currently
> > and what such a framework can bring.
> > (I agree there is a huge room for improvements on unit tests)
> 
> Some of the things I've come across include:
> No standard output format to integrated with continuous regression systems
> No ability to specify specific unit tests or groups of tests to run from the command line
> No standard set of test assertions used across the test suites.
> No standard setup and teardown functions across test suites, state from previous test
> suite can break current
> Requirement to use a python script to orchestrate test runs.
> No support for mocking functionality.
> 

I think libcheck:
https://libcheck.github.io/check/

Ticks most of those boxes, or can have the missing functionality added fairly
easily.

> I know that none of the above couldn't be fixed in our current test application, but I would 
> question if it is effort worthwhile when we take an off the shelf framework, which does all 
> those things and a whole lot more, which has been test and used in a huge variety of
> projects. 
> 
> I certainly willing to look at other frameworks both C and C++ but I yet to find a C framework
> which come close to the usability and flexibility of the popular C++ ones.
> 
> 
> 
> 

Re: [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework

[Ming Zhao(赵明)]

googletest is a very nice test framework and we use it very
extensively in our company(Luminate Wireless), together with gmock.

I understand the resistance from the maintainers that are concerned
about introducing a C++ dependency to a pure C code base. The approach
we take doesn't require any change to the dpdk core, instead we just
use things like a mock PMD(through gmock framework) to allow mocking
the RX/TX code path, disabling huge page usage in test so that the
test can be easily launched without worrying about huge page
collision, etc.

Personally I highly recommend using googletest plus some basic test
cases, which removes a lot of boilerplate and let the developers focus
the test itself.

On Wed, Aug 3, 2016 at 2:57 AM, Doherty, Declan
<declan.doherty@intel.com> wrote:
>
>
>> -----Original Message-----
> ...
>> You are not advocating but the unit test must be written in C++.
>> I don't think it is a good idea to force people to write and maintain the tests
>> in a different language than the code it tests.
>
> I know where you are coming from on this point, and I general would agree if
> it were not for the advantages you get from C++ test framework. Having worked with
> multiple C and C++ frameworks, I've found that one of the biggest advantages of the
> C++ frameworks is the amount of boilerplate code they can save you from writing. Also
> nearly all of C frameworks I've used make use macros to the point that they look more like
> objective C than C. In general I feel that even if the test code is written in C++ the code itself
> should be simple enough that someone with even a passing knowledge of C++ could easily
> understand the intent of the test code.
>
>> > Some of the major advantages of google test that I see over continuing to use
>> the
>> > current test include giving a consist feel to all tests, a powerful test
>> > execution framework which allow individual test suites or tests to be specified
>> > from the command line, support for a standard xunit output which can be
>> integrated
>> > into a continuous build systems, and a very powerful mocking library
>> > which allows much more control over testing failure conditions.
>>
>> It would be interesting to better describe in details what is missing currently
>> and what such a framework can bring.
>> (I agree there is a huge room for improvements on unit tests)
>
> Some of the things I've come across include:
> No standard output format to integrated with continuous regression systems
> No ability to specify specific unit tests or groups of tests to run from the command line
> No standard set of test assertions used across the test suites.
> No standard setup and teardown functions across test suites, state from previous test
> suite can break current
> Requirement to use a python script to orchestrate test runs.
> No support for mocking functionality.
>
> I know that none of the above couldn't be fixed in our current test application, but I would
> question if it is effort worthwhile when we take an off the shelf framework, which does all
> those things and a whole lot more, which has been test and used in a huge variety of
> projects.
>
> I certainly willing to look at other frameworks both C and C++ but I yet to find a C framework
> which come close to the usability and flexibility of the popular C++ ones.
>
>
>

Re: [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework

[Jim Murphy]

Hi,

We are looking at using our existing test environment for our DPDK
applications that will run on our build servers. Hughpages therefore is an
issue. What is involved in running DPDK without hugepages?

Thanks,

Jim


On Wed, Aug 3, 2016 at 1:46 PM, Ming Zhao(赵明) <mzhao@luminatewireless.com>
wrote:

> googletest is a very nice test framework and we use it very
> extensively in our company(Luminate Wireless), together with gmock.
>
> I understand the resistance from the maintainers that are concerned
> about introducing a C++ dependency to a pure C code base. The approach
> we take doesn't require any change to the dpdk core, instead we just
> use things like a mock PMD(through gmock framework) to allow mocking
> the RX/TX code path, disabling huge page usage in test so that the
> test can be easily launched without worrying about huge page
> collision, etc.
>
> Personally I highly recommend using googletest plus some basic test
> cases, which removes a lot of boilerplate and let the developers focus
> the test itself.
>
> On Wed, Aug 3, 2016 at 2:57 AM, Doherty, Declan
> <declan.doherty@intel.com> wrote:
> >
> >
> >> -----Original Message-----
> > ...
> >> You are not advocating but the unit test must be written in C++.
> >> I don't think it is a good idea to force people to write and maintain
> the tests
> >> in a different language than the code it tests.
> >
> > I know where you are coming from on this point, and I general would
> agree if
> > it were not for the advantages you get from C++ test framework. Having
> worked with
> > multiple C and C++ frameworks, I've found that one of the biggest
> advantages of the
> > C++ frameworks is the amount of boilerplate code they can save you from
> writing. Also
> > nearly all of C frameworks I've used make use macros to the point that
> they look more like
> > objective C than C. In general I feel that even if the test code is
> written in C++ the code itself
> > should be simple enough that someone with even a passing knowledge of
> C++ could easily
> > understand the intent of the test code.
> >
> >> > Some of the major advantages of google test that I see over
> continuing to use
> >> the
> >> > current test include giving a consist feel to all tests, a powerful
> test
> >> > execution framework which allow individual test suites or tests to be
> specified
> >> > from the command line, support for a standard xunit output which can
> be
> >> integrated
> >> > into a continuous build systems, and a very powerful mocking library
> >> > which allows much more control over testing failure conditions.
> >>
> >> It would be interesting to better describe in details what is missing
> currently
> >> and what such a framework can bring.
> >> (I agree there is a huge room for improvements on unit tests)
> >
> > Some of the things I've come across include:
> > No standard output format to integrated with continuous regression
> systems
> > No ability to specify specific unit tests or groups of tests to run from
> the command line
> > No standard set of test assertions used across the test suites.
> > No standard setup and teardown functions across test suites, state from
> previous test
> > suite can break current
> > Requirement to use a python script to orchestrate test runs.
> > No support for mocking functionality.
> >
> > I know that none of the above couldn't be fixed in our current test
> application, but I would
> > question if it is effort worthwhile when we take an off the shelf
> framework, which does all
> > those things and a whole lot more, which has been test and used in a
> huge variety of
> > projects.
> >
> > I certainly willing to look at other frameworks both C and C++ but I yet
> to find a C framework
> > which come close to the usability and flexibility of the popular C++
> ones.
> >
> >
> >
>

Re: [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework

[Wiles, Keith]

> On Aug 4, 2016, at 2:47 PM, Jim Murphy <jmurphy@arista.com> wrote:
> 
> Hi,
> 
> We are looking at using our existing test environment for our DPDK
> applications that will run on our build servers. Hughpages therefore is an
> issue. What is involved in running DPDK without huge pages?

Command line option  —no-huge should work. Note two dashs in front.

> 
> Thanks,
> 
> Jim
> 
> 
> On Wed, Aug 3, 2016 at 1:46 PM, Ming Zhao(赵明) <mzhao@luminatewireless.com>
> wrote:
> 
>> googletest is a very nice test framework and we use it very
>> extensively in our company(Luminate Wireless), together with gmock.
>> 
>> I understand the resistance from the maintainers that are concerned
>> about introducing a C++ dependency to a pure C code base. The approach
>> we take doesn't require any change to the dpdk core, instead we just
>> use things like a mock PMD(through gmock framework) to allow mocking
>> the RX/TX code path, disabling huge page usage in test so that the
>> test can be easily launched without worrying about huge page
>> collision, etc.
>> 
>> Personally I highly recommend using googletest plus some basic test
>> cases, which removes a lot of boilerplate and let the developers focus
>> the test itself.
>> 
>> On Wed, Aug 3, 2016 at 2:57 AM, Doherty, Declan
>> <declan.doherty@intel.com> wrote:
>>> 
>>> 
>>>> -----Original Message-----
>>> ...
>>>> You are not advocating but the unit test must be written in C++.
>>>> I don't think it is a good idea to force people to write and maintain
>> the tests
>>>> in a different language than the code it tests.
>>> 
>>> I know where you are coming from on this point, and I general would
>> agree if
>>> it were not for the advantages you get from C++ test framework. Having
>> worked with
>>> multiple C and C++ frameworks, I've found that one of the biggest
>> advantages of the
>>> C++ frameworks is the amount of boilerplate code they can save you from
>> writing. Also
>>> nearly all of C frameworks I've used make use macros to the point that
>> they look more like
>>> objective C than C. In general I feel that even if the test code is
>> written in C++ the code itself
>>> should be simple enough that someone with even a passing knowledge of
>> C++ could easily
>>> understand the intent of the test code.
>>> 
>>>>> Some of the major advantages of google test that I see over
>> continuing to use
>>>> the
>>>>> current test include giving a consist feel to all tests, a powerful
>> test
>>>>> execution framework which allow individual test suites or tests to be
>> specified
>>>>> from the command line, support for a standard xunit output which can
>> be
>>>> integrated
>>>>> into a continuous build systems, and a very powerful mocking library
>>>>> which allows much more control over testing failure conditions.
>>>> 
>>>> It would be interesting to better describe in details what is missing
>> currently
>>>> and what such a framework can bring.
>>>> (I agree there is a huge room for improvements on unit tests)
>>> 
>>> Some of the things I've come across include:
>>> No standard output format to integrated with continuous regression
>> systems
>>> No ability to specify specific unit tests or groups of tests to run from
>> the command line
>>> No standard set of test assertions used across the test suites.
>>> No standard setup and teardown functions across test suites, state from
>> previous test
>>> suite can break current
>>> Requirement to use a python script to orchestrate test runs.
>>> No support for mocking functionality.
>>> 
>>> I know that none of the above couldn't be fixed in our current test
>> application, but I would
>>> question if it is effort worthwhile when we take an off the shelf
>> framework, which does all
>>> those things and a whole lot more, which has been test and used in a
>> huge variety of
>>> projects.
>>> 
>>> I certainly willing to look at other frameworks both C and C++ but I yet
>> to find a C framework
>>> which come close to the usability and flexibility of the popular C++
>> ones.
>>> 
>>> 
>>> 
>> 

Re: [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework

[Yerden Zhumabekov]

On 03.08.2016 15:57, Doherty, Declan wrote:
> Some of the things I've come across include:
> No standard output format to integrated with continuous regression systems
> No ability to specify specific unit tests or groups of tests to run from the command line
> No standard set of test assertions used across the test suites.
> No standard setup and teardown functions across test suites, state from previous test
> suite can break current
> Requirement to use a python script to orchestrate test runs.
> No support for mocking functionality.
>
> I know that none of the above couldn't be fixed in our current test application, but I would
> question if it is effort worthwhile when we take an off the shelf framework, which does all
> those things and a whole lot more, which has been test and used in a huge variety of
> projects.
>
> I certainly willing to look at other frameworks both C and C++ but I yet to find a C framework
> which come close to the usability and flexibility of the popular C++ ones.

We use cmocka.org for tests. Written in C. It has support for:
* mocking;
* setup/teardown;
* asserts;
* test groups.

Output is nicely formatted.

Re: [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework

[Thomas Monjalon]

2016-08-04 19:55, Wiles, Keith:
> 
> > On Aug 4, 2016, at 2:47 PM, Jim Murphy <jmurphy@arista.com> wrote:
> > 
> > Hi,
> > 
> > We are looking at using our existing test environment for our DPDK
> > applications that will run on our build servers. Hughpages therefore is an
> > issue. What is involved in running DPDK without huge pages?
> 
> Command line option  —no-huge should work. Note two dashs in front.

Most of drivers still require hugepages.
A big rework would be needed to make them work without hugepages.

Re: [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework

[Remy Horton]

On 05/08/2016 08:41, Yerden Zhumabekov wrote:
[..]
> We use cmocka.org for tests. Written in C. It has support for:
> * mocking;
> * setup/teardown;
> * asserts;
> * test groups.
>
> Output is nicely formatted.

Cmocka's mocking relies on Gnu ld's --wrap feature, which has problems 
if the function being mocked is defined in the same compilation unit 
that it is used. Pity really as otherwise it looked quite good to me.

..Remy

Re: [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework

[Neil Horman]

On Fri, Aug 05, 2016 at 10:11:56AM +0100, Remy Horton wrote:
> 
> On 05/08/2016 08:41, Yerden Zhumabekov wrote:
> [..]
> > We use cmocka.org for tests. Written in C. It has support for:
> > * mocking;
> > * setup/teardown;
> > * asserts;
> > * test groups.
> > 
> > Output is nicely formatted.
> 
> Cmocka's mocking relies on Gnu ld's --wrap feature, which has problems if
> the function being mocked is defined in the same compilation unit that it is
> used. Pity really as otherwise it looked quite good to me.
> 
Can't you use ld's --undefined option to get the correct behavior?  I thought
that was specifically what it was there for.

Neil

> ..Remy
> 

Re: [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework

[Remy Horton]

On 05/08/2016 13:59, Neil Horman wrote:
> On Fri, Aug 05, 2016 at 10:11:56AM +0100, Remy Horton wrote:
[..]
>> Cmocka's mocking relies on Gnu ld's --wrap feature, which has problems if
>> the function being mocked is defined in the same compilation unit that it is
>> used. Pity really as otherwise it looked quite good to me.
>>
> Can't you use ld's --undefined option to get the correct behavior?  I thought
> that was specifically what it was there for.

Not sure - I'll try playing around with it when I next have some spare 
time.. :)

The C-Mock extension (https://github.com/hjagodzinski/C-Mock) for GMock 
uses some dynamic linker trickery which I'm guessing is probably not C++ 
specific, and I quite like that approach as it avoids the need to 
pre-specify in makefiles which functions are to be mocked.

..Remy