* [dpdk-dev] [RFC 1/4] mk: Add support for C++ compilation
2016-08-02 20:37 [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework Declan Doherty
@ 2016-08-02 20:37 ` Declan Doherty
2016-08-02 20:37 ` [dpdk-dev] [RFC 2/4] examples: add c++ example application Declan Doherty
` (3 subsequent siblings)
4 siblings, 0 replies; 19+ messages in thread
From: Declan Doherty @ 2016-08-02 20:37 UTC (permalink / raw)
To: dev; +Cc: Anatoly Burakov, 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
^ permalink raw reply [flat|nested] 19+ messages in thread* [dpdk-dev] [RFC 2/4] examples: add c++ example application
2016-08-02 20:37 [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework Declan Doherty
2016-08-02 20:37 ` [dpdk-dev] [RFC 1/4] mk: Add support for C++ compilation Declan Doherty
@ 2016-08-02 20:37 ` Declan Doherty
2016-08-02 20:37 ` [dpdk-dev] [RFC 3/4] eal: add command line option to log output to stdout Declan Doherty
` (2 subsequent siblings)
4 siblings, 0 replies; 19+ messages in thread
From: Declan Doherty @ 2016-08-02 20:37 UTC (permalink / raw)
To: dev; +Cc: Anatoly Burakov, 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 ++
| 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;
+}
--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
^ permalink raw reply [flat|nested] 19+ messages in thread* [dpdk-dev] [RFC 3/4] eal: add command line option to log output to stdout
2016-08-02 20:37 [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework Declan Doherty
2016-08-02 20:37 ` [dpdk-dev] [RFC 1/4] mk: Add support for C++ compilation Declan Doherty
2016-08-02 20:37 ` [dpdk-dev] [RFC 2/4] examples: add c++ example application Declan Doherty
@ 2016-08-02 20:37 ` Declan Doherty
2016-08-03 11:25 ` Neil Horman
2016-08-02 20:37 ` [dpdk-dev] [RFC 4/4] app/test-gtest: example google test application Declan Doherty
2016-08-02 21:52 ` [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework Thomas Monjalon
4 siblings, 1 reply; 19+ messages in thread
From: Declan Doherty @ 2016-08-02 20:37 UTC (permalink / raw)
To: dev; +Cc: 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
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [dpdk-dev] [RFC 3/4] eal: add command line option to log output to stdout
2016-08-02 20:37 ` [dpdk-dev] [RFC 3/4] eal: add command line option to log output to stdout Declan Doherty
@ 2016-08-03 11:25 ` Neil Horman
0 siblings, 0 replies; 19+ messages in thread
From: Neil Horman @ 2016-08-03 11:25 UTC (permalink / raw)
To: Declan Doherty; +Cc: dev
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [dpdk-dev] [RFC 4/4] app/test-gtest: example google test application
2016-08-02 20:37 [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework Declan Doherty
` (2 preceding siblings ...)
2016-08-02 20:37 ` [dpdk-dev] [RFC 3/4] eal: add command line option to log output to stdout Declan Doherty
@ 2016-08-02 20:37 ` Declan Doherty
2016-08-02 21:52 ` [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework Thomas Monjalon
4 siblings, 0 replies; 19+ messages in thread
From: Declan Doherty @ 2016-08-02 20:37 UTC (permalink / raw)
To: dev; +Cc: 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
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework
2016-08-02 20:37 [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework Declan Doherty
` (3 preceding siblings ...)
2016-08-02 20:37 ` [dpdk-dev] [RFC 4/4] app/test-gtest: example google test application Declan Doherty
@ 2016-08-02 21:52 ` Thomas Monjalon
2016-08-03 9:16 ` Remy Horton
` (2 more replies)
4 siblings, 3 replies; 19+ messages in thread
From: Thomas Monjalon @ 2016-08-02 21:52 UTC (permalink / raw)
To: Declan Doherty; +Cc: dev
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)
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework
2016-08-02 21:52 ` [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework Thomas Monjalon
@ 2016-08-03 9:16 ` Remy Horton
2016-08-03 9:57 ` Doherty, Declan
2016-08-03 11:31 ` Neil Horman
2 siblings, 0 replies; 19+ messages in thread
From: Remy Horton @ 2016-08-03 9:16 UTC (permalink / raw)
To: Thomas Monjalon, Declan Doherty; +Cc: dev
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework
2016-08-02 21:52 ` [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework Thomas Monjalon
2016-08-03 9:16 ` Remy Horton
@ 2016-08-03 9:57 ` Doherty, Declan
2016-08-03 12:51 ` Neil Horman
` (2 more replies)
2016-08-03 11:31 ` Neil Horman
2 siblings, 3 replies; 19+ messages in thread
From: Doherty, Declan @ 2016-08-03 9:57 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
> -----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.
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework
2016-08-03 9:57 ` Doherty, Declan
@ 2016-08-03 12:51 ` Neil Horman
2016-08-03 20:46 ` Ming Zhao
2016-08-05 7:41 ` Yerden Zhumabekov
2 siblings, 0 replies; 19+ messages in thread
From: Neil Horman @ 2016-08-03 12:51 UTC (permalink / raw)
To: Doherty, Declan; +Cc: Thomas Monjalon, dev
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.
>
>
>
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework
2016-08-03 9:57 ` Doherty, Declan
2016-08-03 12:51 ` Neil Horman
@ 2016-08-03 20:46 ` Ming Zhao
2016-08-04 19:47 ` Jim Murphy
2016-08-05 7:41 ` Yerden Zhumabekov
2 siblings, 1 reply; 19+ messages in thread
From: Ming Zhao(赵明) @ 2016-08-03 20:46 UTC (permalink / raw)
To: Doherty, Declan; +Cc: Thomas Monjalon, dev
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.
>
>
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework
2016-08-03 20:46 ` Ming Zhao
@ 2016-08-04 19:47 ` Jim Murphy
2016-08-04 19:55 ` Wiles, Keith
0 siblings, 1 reply; 19+ messages in thread
From: Jim Murphy @ 2016-08-04 19:47 UTC (permalink / raw)
To: Ming Zhao(赵明); +Cc: Doherty, Declan, Thomas Monjalon, dev
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.
> >
> >
> >
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework
2016-08-04 19:47 ` Jim Murphy
@ 2016-08-04 19:55 ` Wiles, Keith
2016-08-05 7:42 ` Thomas Monjalon
0 siblings, 1 reply; 19+ messages in thread
From: Wiles, Keith @ 2016-08-04 19:55 UTC (permalink / raw)
To: Jim Murphy
Cc: Ming Zhao(赵明), Doherty, Declan, Thomas Monjalon, dev
> 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.
>>>
>>>
>>>
>>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework
2016-08-04 19:55 ` Wiles, Keith
@ 2016-08-05 7:42 ` Thomas Monjalon
0 siblings, 0 replies; 19+ messages in thread
From: Thomas Monjalon @ 2016-08-05 7:42 UTC (permalink / raw)
To: Wiles, Keith, Jim Murphy
Cc: Ming Zhao(赵明), Doherty, Declan, dev
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework
2016-08-03 9:57 ` Doherty, Declan
2016-08-03 12:51 ` Neil Horman
2016-08-03 20:46 ` Ming Zhao
@ 2016-08-05 7:41 ` Yerden Zhumabekov
2016-08-05 9:11 ` Remy Horton
2 siblings, 1 reply; 19+ messages in thread
From: Yerden Zhumabekov @ 2016-08-05 7:41 UTC (permalink / raw)
To: Doherty, Declan, Thomas Monjalon; +Cc: dev
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework
2016-08-05 7:41 ` Yerden Zhumabekov
@ 2016-08-05 9:11 ` Remy Horton
2016-08-05 12:59 ` Neil Horman
0 siblings, 1 reply; 19+ messages in thread
From: Remy Horton @ 2016-08-05 9:11 UTC (permalink / raw)
To: Yerden Zhumabekov, Doherty, Declan, Thomas Monjalon; +Cc: dev
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework
2016-08-05 9:11 ` Remy Horton
@ 2016-08-05 12:59 ` Neil Horman
2016-08-05 14:54 ` Remy Horton
0 siblings, 1 reply; 19+ messages in thread
From: Neil Horman @ 2016-08-05 12:59 UTC (permalink / raw)
To: Remy Horton; +Cc: Yerden Zhumabekov, Doherty, Declan, Thomas Monjalon, dev
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
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework
2016-08-05 12:59 ` Neil Horman
@ 2016-08-05 14:54 ` Remy Horton
0 siblings, 0 replies; 19+ messages in thread
From: Remy Horton @ 2016-08-05 14:54 UTC (permalink / raw)
To: Neil Horman; +Cc: Yerden Zhumabekov, Doherty, Declan, Thomas Monjalon, dev
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework
2016-08-02 21:52 ` [dpdk-dev] [RFC 0/4] Use Google Test as DPDK unit test framework Thomas Monjalon
2016-08-03 9:16 ` Remy Horton
2016-08-03 9:57 ` Doherty, Declan
@ 2016-08-03 11:31 ` Neil Horman
2 siblings, 0 replies; 19+ messages in thread
From: Neil Horman @ 2016-08-03 11:31 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: Declan Doherty, dev
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
^ permalink raw reply [flat|nested] 19+ messages in thread