date:20170120

[lng-odp] [PATCH v4 3/4] helper: move thread implementation under platform

2017-01-20 Thread Mike Holmes

Only the portable api is built by default, use --enable-helper-extn
to enable non portable APIs for a helper platform

Signed-off-by: Mike Holmes 
---
 configure.ac   |  17 +-
 example/Makefile.inc   |   2 +-
 helper/Makefile.am |  16 +-
 .../helper/platform/linux-generic/threads_extn.h   | 112 
 helper/include/odp/helper/threads.h|  76 -
 helper/m4/configure.m4 |  11 +
 helper/platform/linux-generic/thread.c | 313 +
 helper/test/Makefile.am|  19 +-
 helper/test/linux-generic/Makefile.am  |   5 +
 helper/test/{ => linux-generic}/process.c  |   2 +-
 helper/test/{ => linux-generic}/thread.c   |   2 +-
 helper/threads.c   | 238 +---
 ...inux.pc.in => libodphelper-linux-generic.pc.in} |   4 +-
 test/Makefile.inc  |   2 +-
 test/common_plat/validation/api/Makefile.inc   |   2 +-
 test/linux-generic/Makefile.inc|   2 +-
 16 files changed, 498 insertions(+), 325 deletions(-)
 create mode 100644 
helper/include/odp/helper/platform/linux-generic/threads_extn.h
 create mode 100644 helper/platform/linux-generic/thread.c
 create mode 100644 helper/test/linux-generic/Makefile.am
 rename helper/test/{ => linux-generic}/process.c (97%)
 rename helper/test/{ => linux-generic}/thread.c (97%)
 rename pkgconfig/{libodphelper-linux.pc.in => 
libodphelper-linux-generic.pc.in} (72%)

diff --git a/configure.ac b/configure.ac
index 1384130..2cf6536 100644
--- a/configure.ac
+++ b/configure.ac
@@ -138,6 +138,18 @@ AC_SUBST([with_platform])
 AC_SUBST([platform_with_platform], ["platform/${with_platform}"])
 
 ##
+# Determine which helper platform to build for
+##
+AC_ARG_WITH([helper_platform],
+[AS_HELP_STRING([--with-helper_platform=platform],
+   [select helper platform to be used, default linux-generic])],
+[],
+[with_helper_platform=${with_platform}
+])
+
+AC_SUBST([with_helper_platform])
+
+##
 # Run platform specific checks and settings
 ##
 IMPLEMENTATION_NAME=""
@@ -202,6 +214,7 @@ AM_CONDITIONAL([test_example], [test x$test_example = xyes 
])
 AM_CONDITIONAL([HAVE_DOXYGEN], [test "x${DOXYGEN}" = "xdoxygen"])
 AM_CONDITIONAL([user_guide], [test "x${user_guides}" = "xyes" ])
 AM_CONDITIONAL([HAVE_MSCGEN], [test "x${MSCGEN}" = "xmscgen"])
+AM_CONDITIONAL([helper_extn], [test x$helper_extn = xyes ])
 
 ##
 # Setup doxygen documentation
@@ -295,7 +308,7 @@ AM_CXXFLAGS="-std=c++11"
 
 AC_CONFIG_FILES([Makefile
 pkgconfig/libodp-linux.pc
-pkgconfig/libodphelper-linux.pc
+pkgconfig/libodphelper-linux-generic.pc
 ])
 
 AC_SEARCH_LIBS([timer_create],[rt posix4])
@@ -322,6 +335,8 @@ AC_MSG_RESULT([
implementation_name:${IMPLEMENTATION_NAME}
ARCH_DIR${ARCH_DIR}
with_platform:  ${with_platform}
+   with_helper_platform:   ${with_helper_platform}
+   helper_extn:${helper_extn}
prefix: ${prefix}
sysconfdir: ${sysconfdir}
libdir: ${libdir}
diff --git a/example/Makefile.inc b/example/Makefile.inc
index 19d3994..ea596d5 100644
--- a/example/Makefile.inc
+++ b/example/Makefile.inc
@@ -1,6 +1,6 @@
 include $(top_srcdir)/platform/@with_platform@/Makefile.inc
 LIB   = $(top_builddir)/lib
-LDADD = $(LIB)/libodp-linux.la $(LIB)/libodphelper-linux.la
+LDADD = $(LIB)/libodp-linux.la $(LIB)/libodphelper-@with_helper_platform@.la
 AM_CFLAGS += \
-I$(srcdir) \
-I$(top_srcdir)/example \
diff --git a/helper/Makefile.am b/helper/Makefile.am
index 62e55cc..9b2f18a 100644
--- a/helper/Makefile.am
+++ b/helper/Makefile.am
@@ -1,7 +1,7 @@
 include $(top_srcdir)/platform/@with_platform@/Makefile.inc
 
 pkgconfigdir = $(libdir)/pkgconfig
-pkgconfig_DATA = $(top_builddir)/pkgconfig/libodphelper-linux.pc
+pkgconfig_DATA = $(top_builddir)/pkgconfig/libodphelper-linux-generic.pc
 
 LIB   = $(top_builddir)/lib
 AM_CFLAGS  = -I$(srcdir)/include
@@ -25,6 +25,11 @@ helperinclude_HEADERS = \
  $(srcdir)/include/odp/helper/threads.h \
  $(srcdir)/include/odp/helper/udp.h
 
+if helper_extn
+helperinclude_HEADERS += \
+   
$(srcdir)/include/odp/helper/platform/@with_helper_platform@/threads_extn.h
+endif
+
 noinst_HEADERS = \
 $(srcdir)/odph_debug.h \

[lng-odp] [PATCH v4 4/4] helper: remove dependence on test dir

2017-01-20 Thread Mike Holmes

There is no reason that the helpers need to depend on the test directory
so remove the offending links

Signed-off-by: Mike Holmes 
---
 helper/test/Makefile.am | 25 ---
 helper/test/chksum.c| 18 
 helper/test/cuckootable.c   |  4 +-
 helper/test/iplookuptable.c |  4 +-
 helper/test/linux-generic/process.c | 14 +++---
 helper/test/linux-generic/thread.c  | 14 +++---
 helper/test/odpthreads.c| 18 
 helper/test/parse.c | 86 ++---
 helper/test/table.c | 12 +++---
 9 files changed, 105 insertions(+), 90 deletions(-)

diff --git a/helper/test/Makefile.am b/helper/test/Makefile.am
index 7d55ae6..1c50282 100644
--- a/helper/test/Makefile.am
+++ b/helper/test/Makefile.am
@@ -1,10 +1,26 @@
-include $(top_srcdir)/test/Makefile.inc
+include $(top_srcdir)/platform/@with_platform@/Makefile.inc
 
-AM_CFLAGS += -I$(srcdir)/common
+LIB   = $(top_builddir)/lib
+
+#in the following line, the libs using the symbols should come before
+#the libs containing them! The includer is given a chance to add things
+#before libodp by setting PRE_LDADD before the inclusion.
+LDADD = $(PRE_LDADD) $(LIB)/libodphelper-@with_helper_platform@.la 
$(LIB)/libodp-linux.la
+
+INCFLAGS = \
+   -I$(top_builddir)/platform/@with_platform@/include \
+   -I$(top_srcdir)/helper/include \
+   -I$(top_srcdir)/helper/platform/@with_helper_platform@/include \
+   -I$(top_srcdir)/include \
+   -I$(top_srcdir)/platform/@with_platform@/include \
+   -I$(top_builddir)/include \
+   -I$(top_srcdir)/helper
+
+ODP_PLATFORM=${with_platform}
+
+AM_CFLAGS += $(INCFLAGS)
 AM_LDFLAGS += -static
 
-TESTS_ENVIRONMENT += TEST_DIR=${builddir}
-
 EXECUTABLES = chksum$(EXEEXT) \
   cuckootable$(EXEEXT) \
   parse$(EXEEXT)\
@@ -38,7 +54,6 @@ EXTRA_DIST = odpthreads_as_processes odpthreads_as_pthreads
 dist_chksum_SOURCES = chksum.c
 dist_cuckootable_SOURCES = cuckootable.c
 dist_odpthreads_SOURCES = odpthreads.c
-odpthreads_LDADD = $(LIB)/libodphelper-@with_helper_platform@.la 
$(LIB)/libodp-linux.la
 dist_parse_SOURCES = parse.c
 dist_table_SOURCES = table.c
 dist_iplookuptable_SOURCES = iplookuptable.c
diff --git a/helper/test/chksum.c b/helper/test/chksum.c
index 749d495..7c572ae 100644
--- a/helper/test/chksum.c
+++ b/helper/test/chksum.c
@@ -4,7 +4,7 @@
  * SPDX-License-Identifier: BSD-3-Clause
  */
 
-#include 
+#include "odph_debug.h"
 #include 
 #include 
 #include 
@@ -21,7 +21,7 @@ struct udata_struct {
 };
 
 /* Create additional dataplane threads */
-int main(int argc TEST_UNUSED, char *argv[] TEST_UNUSED)
+int main(int argc ODPH_UNUSED, char *argv[] ODPH_UNUSED)
 {
odp_instance_t instance;
int status = 0;
@@ -41,17 +41,17 @@ int main(int argc TEST_UNUSED, char *argv[] TEST_UNUSED)
odp_pool_capability_t capa;
 
if (odp_init_global(, NULL, NULL)) {
-   LOG_ERR("Error: ODP global init failed.\n");
+   ODPH_ERR("Error: ODP global init failed.\n");
exit(EXIT_FAILURE);
}
 
if (odp_init_local(instance, ODP_THREAD_WORKER)) {
-   LOG_ERR("Error: ODP local init failed.\n");
+   ODPH_ERR("Error: ODP local init failed.\n");
exit(EXIT_FAILURE);
}
 
if (odp_pool_capability() < 0) {
-   LOG_ERR("Error: ODP global init failed.\n");
+   ODPH_ERR("Error: ODP global init failed.\n");
exit(EXIT_FAILURE);
}
 
@@ -91,12 +91,12 @@ int main(int argc TEST_UNUSED, char *argv[] TEST_UNUSED)
eth->type = odp_cpu_to_be_16(ODPH_ETHTYPE_IPV4);
 
if (odph_ipv4_addr_parse(, "192.168.0.1")) {
-   LOG_ERR("Error: parse ip\n");
+   ODPH_ERR("Error: parse ip\n");
return -1;
}
 
if (odph_ipv4_addr_parse(, "192.168.0.2")) {
-   LOG_ERR("Error: parse ip\n");
+   ODPH_ERR("Error: parse ip\n");
return -1;
}
 
@@ -139,12 +139,12 @@ int main(int argc TEST_UNUSED, char *argv[] TEST_UNUSED)
return -1;
 
if (odp_term_local()) {
-   LOG_ERR("Error: ODP local term failed.\n");
+   ODPH_ERR("Error: ODP local term failed.\n");
exit(EXIT_FAILURE);
}
 
if (odp_term_global(instance)) {
-   LOG_ERR("Error: ODP global term failed.\n");
+   ODPH_ERR("Error: ODP global term failed.\n");
exit(EXIT_FAILURE);
}
 
diff --git a/helper/test/cuckootable.c b/helper/test/cuckootable.c
index 5b4333b..6736f2b 100644
--- a/helper/test/cuckootable.c
+++ b/helper/test/cuckootable.c
@@ -48,7 +48,7 @@
 #include 
 
 #include 
-#include 
+#include 
 #include <../odph_cuckootable.h>
 
 
/***
@@ -534,7 +534,7 @@

[lng-odp] [PATCH v4 2/4] helper: cleanup Linux rename to thread

2017-01-20 Thread Mike Holmes

Remove the OS specific Linux filename and use the name of the generic
apis it contains which is for odp_threads

Signed-off-by: Mike Holmes 
---
 example/classifier/odp_classifier.c | 2 +-
 example/generator/odp_generator.c   | 2 +-
 example/ipsec/odp_ipsec.c   | 2 +-
 example/l2fwd_simple/odp_l2fwd_simple.c | 2 +-
 example/l3fwd/odp_l3fwd.c   | 2 +-
 example/packet/odp_pktio.c  | 2 +-
 example/switch/odp_switch.c | 2 +-
 example/time/time_global_test.c | 5 +++--
 example/timer/odp_timer_test.c  | 2 +-
 helper/Makefile.am  | 6 +++---
 helper/include/odp/helper/{linux.h => threads.h}| 2 --
 helper/test/odpthreads.c| 2 +-
 helper/test/process.c   | 2 +-
 helper/test/thread.c| 2 +-
 helper/{linux.c => threads.c}   | 2 +-
 test/common_plat/common/odp_cunit_common.c  | 2 +-
 test/common_plat/miscellaneous/odp_api_from_cpp.cpp | 2 +-
 test/common_plat/performance/odp_crypto.c   | 2 +-
 test/common_plat/performance/odp_l2fwd.c| 2 +-
 test/common_plat/performance/odp_pktio_perf.c   | 2 +-
 test/common_plat/performance/odp_sched_latency.c| 2 +-
 test/common_plat/performance/odp_scheduling.c   | 2 +-
 test/common_plat/validation/api/timer/timer.c   | 2 +-
 test/linux-generic/mmap_vlan_ins/mmap_vlan_ins.c| 2 +-
 test/linux-generic/pktio_ipc/ipc_common.h   | 2 +-
 test/linux-generic/ring/ring_stress.c   | 2 +-
 26 files changed, 29 insertions(+), 30 deletions(-)
 rename helper/include/odp/helper/{linux.h => threads.h} (99%)
 rename helper/{linux.c => threads.c} (99%)

diff --git a/example/classifier/odp_classifier.c 
b/example/classifier/odp_classifier.c
index 1bd2414..c2f69d4 100644
--- a/example/classifier/odp_classifier.c
+++ b/example/classifier/odp_classifier.c
@@ -12,9 +12,9 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/example/generator/odp_generator.c 
b/example/generator/odp_generator.c
index ccd47f6..194c0a0 100644
--- a/example/generator/odp_generator.c
+++ b/example/generator/odp_generator.c
@@ -20,7 +20,7 @@
 
 #include 
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/example/ipsec/odp_ipsec.c b/example/ipsec/odp_ipsec.c
index 7e34d06..d686160 100644
--- a/example/ipsec/odp_ipsec.c
+++ b/example/ipsec/odp_ipsec.c
@@ -24,7 +24,7 @@
 
 #include 
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/example/l2fwd_simple/odp_l2fwd_simple.c 
b/example/l2fwd_simple/odp_l2fwd_simple.c
index 0682d2d..2473a11 100644
--- a/example/l2fwd_simple/odp_l2fwd_simple.c
+++ b/example/l2fwd_simple/odp_l2fwd_simple.c
@@ -10,9 +10,9 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
+#include 
 
 #define POOL_NUM_PKT 8192
 #define POOL_SEG_LEN 1856
diff --git a/example/l3fwd/odp_l3fwd.c b/example/l3fwd/odp_l3fwd.c
index 441e812..4e35b64 100644
--- a/example/l3fwd/odp_l3fwd.c
+++ b/example/l3fwd/odp_l3fwd.c
@@ -14,11 +14,11 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include "odp_l3fwd_db.h"
 #include "odp_l3fwd_lpm.h"
diff --git a/example/packet/odp_pktio.c b/example/packet/odp_pktio.c
index d1135cb..6e24deb 100644
--- a/example/packet/odp_pktio.c
+++ b/example/packet/odp_pktio.c
@@ -13,9 +13,9 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
+#include 
 
 /** @def MAX_WORKERS
  * @brief Maximum number of worker threads
diff --git a/example/switch/odp_switch.c b/example/switch/odp_switch.c
index f9c7176..2bbce10 100644
--- a/example/switch/odp_switch.c
+++ b/example/switch/odp_switch.c
@@ -11,9 +11,9 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
+#include 
 
 /** Maximum number of worker threads */
 #define MAX_WORKERS32
diff --git a/example/time/time_global_test.c b/example/time/time_global_test.c
index 380ec52..dd33949 100644
--- a/example/time/time_global_test.c
+++ b/example/time/time_global_test.c
@@ -4,10 +4,11 @@
  * SPDX-License-Identifier: BSD-3-Clause
  */
 
+#include 
+
 #include 
 #include 
-#include 
-#include 
+#include 
 
 #define MAX_WORKERS32
 #define ITERATION_NUM  2048
diff --git a/example/timer/odp_timer_test.c b/example/timer/odp_timer_test.c
index 035ab2e..b847e2b 100644
--- a/example/timer/odp_timer_test.c
+++ b/example/timer/odp_timer_test.c
@@ -14,7 +14,7 @@
 #include 
 
 /* ODP helper for Linux apps */
-#include 
+#include 
 
 /* GNU lib C */
 #include 
diff --git a/helper/Makefile.am b/helper/Makefile.am
index 9d0036d..62e55cc 100644
--- a/helper/Makefile.am
+++ b/helper/Makefile.am
@@ -14,7 +14,6 @@ AM_LDFLAGS += -version-number '$(ODPHELPER_LIBSO_VERSION)'

[lng-odp] [PATCH v4 1/4] configure: use helper configure.m4

2017-01-20 Thread Mike Holmes

Don't keep helper data in the  main configure, split it to an m4 just
like the other sub dirs

Signed-off-by: Mike Holmes 
---
 configure.ac   | 2 --
 helper/m4/configure.m4 | 3 +++
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 67d60d2..1384130 100644
--- a/configure.ac
+++ b/configure.ac
@@ -294,8 +294,6 @@ AM_CFLAGS="$AM_CFLAGS $ODP_CFLAGS"
 AM_CXXFLAGS="-std=c++11"
 
 AC_CONFIG_FILES([Makefile
-helper/Makefile
-helper/test/Makefile
 pkgconfig/libodp-linux.pc
 pkgconfig/libodphelper-linux.pc
 ])
diff --git a/helper/m4/configure.m4 b/helper/m4/configure.m4
index 480f79b..7b208fa 100644
--- a/helper/m4/configure.m4
+++ b/helper/m4/configure.m4
@@ -7,3 +7,6 @@ AC_ARG_ENABLE([test-helper],
 [if test "x$enableval" = "xyes"; then
 test_helper=yes
 fi])
+
+AC_CONFIG_FILES([helper/Makefile
+   helper/test/Makefile])
-- 
2.9.3

[lng-odp] [PATCH v4 0/4] remove Linux specifics and dependence on test

2017-01-20 Thread Mike Holmes

Starting with some clean up, rename the Linux specific files and then move them
to a platform specific directory. A new configure option is introduced
"with-helper-platform", this defaults to match the existing odp selector
"with-platform" so that there is no operational change.

With the move made the default is to build only the portable helper API, if the
legacy and previously unused Linux thread APIs are needed they can be built in
with --enable-helper-extn

Then remove the dependence on the test directory.

v2:
sort some lists into alphabetical order (Maxim)
addtional code simplification removing a .h helper(Christophe)

v3:
rebase
whitespace error is there due to matching existing formatting in file

v4:
remove CXX, it is not used
alignment in configure.ac

Carried from v3
For the series:
Reviewed-by: Christophe Milard 


Mike Holmes (4):
  configure: use helper configure.m4
  helper: cleanup Linux rename to thread
  helper: move thread implementation under platform
  helper: remove dependence on test dir

 configure.ac   |  19 +-
 example/Makefile.inc   |   2 +-
 example/classifier/odp_classifier.c|   2 +-
 example/generator/odp_generator.c  |   2 +-
 example/ipsec/odp_ipsec.c  |   2 +-
 example/l2fwd_simple/odp_l2fwd_simple.c|   2 +-
 example/l3fwd/odp_l3fwd.c  |   2 +-
 example/packet/odp_pktio.c |   2 +-
 example/switch/odp_switch.c|   2 +-
 example/time/time_global_test.c|   5 +-
 example/timer/odp_timer_test.c |   2 +-
 helper/Makefile.am |  22 +-
 .../helper/platform/linux-generic/threads_extn.h   | 112 
 helper/include/odp/helper/{linux.h => threads.h}   |  78 -
 helper/m4/configure.m4 |  14 +
 helper/platform/linux-generic/thread.c | 313 +
 helper/test/Makefile.am|  42 ++-
 helper/test/chksum.c   |  18 +-
 helper/test/cuckootable.c  |   4 +-
 helper/test/iplookuptable.c|   4 +-
 helper/test/linux-generic/Makefile.am  |   5 +
 helper/test/{ => linux-generic}/process.c  |  16 +-
 helper/test/{ => linux-generic}/thread.c   |  16 +-
 helper/test/odpthreads.c   |  20 +-
 helper/test/parse.c|  86 +++---
 helper/test/table.c|  12 +-
 helper/{linux.c => threads.c}  | 240 +---
 ...inux.pc.in => libodphelper-linux-generic.pc.in} |   4 +-
 test/Makefile.inc  |   2 +-
 test/common_plat/common/odp_cunit_common.c |   2 +-
 .../common_plat/miscellaneous/odp_api_from_cpp.cpp |   2 +-
 test/common_plat/performance/odp_crypto.c  |   2 +-
 test/common_plat/performance/odp_l2fwd.c   |   2 +-
 test/common_plat/performance/odp_pktio_perf.c  |   2 +-
 test/common_plat/performance/odp_sched_latency.c   |   2 +-
 test/common_plat/performance/odp_scheduling.c  |   2 +-
 test/common_plat/validation/api/Makefile.inc   |   2 +-
 test/common_plat/validation/api/timer/timer.c  |   2 +-
 test/linux-generic/Makefile.inc|   2 +-
 test/linux-generic/mmap_vlan_ins/mmap_vlan_ins.c   |   2 +-
 test/linux-generic/pktio_ipc/ipc_common.h  |   2 +-
 test/linux-generic/ring/ring_stress.c  |   2 +-
 42 files changed, 632 insertions(+), 444 deletions(-)
 create mode 100644 
helper/include/odp/helper/platform/linux-generic/threads_extn.h
 rename helper/include/odp/helper/{linux.h => threads.h} (74%)
 create mode 100644 helper/platform/linux-generic/thread.c
 create mode 100644 helper/test/linux-generic/Makefile.am
 rename helper/test/{ => linux-generic}/process.c (84%)
 rename helper/test/{ => linux-generic}/thread.c (84%)
 rename helper/{linux.c => threads.c} (67%)
 rename pkgconfig/{libodphelper-linux.pc.in => 
libodphelper-linux-generic.pc.in} (72%)

-- 
2.9.3

Re: [lng-odp] [PATCH 1/2] helper: fix compilation with warnings

2017-01-20 Thread Mike Holmes

I think this needs a rebase, latest master has brought new issues with
the extra flags

 f2e960d :2016-12-29 - (HEAD -> master) configure.ac: helper: print
debug config option 
* de503c9 :2016-12-29 - helper: fix compilation with warnings 
* 3875d6e :2017-01-13 - (tag: v1.13.0.0, origin/master, origin/HEAD)
update API version number from v1.12.0.0 to v1.13.0.0 num_buckets; i++) {
^
cuckootable.c: In function ‘odph_cuckoo_table_get_value’:
cuckootable.c:656:55: error: unused parameter ‘buffer_size’
[-Werror=unused-parameter]
   odph_table_t tbl, void *key, void *buffer, uint32_t buffer_size)
   ^~~
iplookuptable.c: In function ‘odph_iplookup_table_create’:
iplookuptable.c:439:30: error: unused parameter ‘ODP_IGNORED_1’
[-Werror=unused-parameter]
   const char *name, uint32_t ODP_IGNORED_1,
  ^
iplookuptable.c:440:12: error: unused parameter ‘ODP_IGNORED_2’
[-Werror=unused-parameter]
   uint32_t ODP_IGNORED_2, uint32_t value_size)
^
iplookuptable.c: In function ‘odph_iplookup_table_get_value’:
iplookuptable.c:709:55: error: unused parameter ‘buffer_size’
[-Werror=unused-parameter]
   odph_table_t tbl, void *key, void *buffer, uint32_t buffer_size)
   ^~~
iplookuptable.c: In function ‘odph_iplookup_table_remove_value’:
iplookuptable.c:891:19: error: comparison is always false due to
limited range of data type [-Werror=type-limits]
  if (prefix->cidr < 0)
   ^
cc1: all warnings being treated as errors
cc1: all warnings being treated as errors



On 9 January 2017 at 13:37, Maxim Uvarov  wrote:
> On 01/09/17 21:10, Mike Holmes wrote:
>>
>>
>> On 29 December 2016 at 11:40, Maxim Uvarov > > wrote:
>>
>> After turning on lost CFLAGS for checking errors,
>> following things needs to be corrected to make code
>> compile.
>>
>>
>> Which cflags ? I looked in 2/2 and  assume it was debug print, but that
>> was not lost just hard wired to 1, was this a bug when debug print was = 0 ?
>>
>
> patch 2/2 passes all cflags to helper with:
> -AM_CFLAGS  = -I$(srcdir)/include
> +AM_CFLAGS += -I$(srcdir)/include
>
> with configured option -DODPH_DEBUG_PRINT=0
>
> but passing cflags triggers a lot of gcc warnings which we threat as
> errors. So patch 1 is needed before patch 2.
>
> Maxim.
>
>
>
>>
>> Signed-off-by: Maxim Uvarov > >
>> ---
>>  helper/chksum.c  |  4 ++--
>>  helper/hashtable.c   | 42 ++
>>  helper/lineartable.c | 27 +--
>>  helper/linux.c   |  2 +-
>>  4 files changed, 46 insertions(+), 29 deletions(-)
>>
>> diff --git a/helper/chksum.c b/helper/chksum.c
>> index b7eef67..f740618 100644
>> --- a/helper/chksum.c
>> +++ b/helper/chksum.c
>> @@ -49,7 +49,7 @@ static uint32_t data_seg_sum(uint8_t   *data8_ptr,
>> data_len--;
>> }
>>
>> -   data16_ptr = (uint16_t *)data8_ptr;
>> +   data16_ptr = (uint16_t *)(void *)data8_ptr;
>>
>> /* The following code tries to gain a modest performance
>> enhancement by
>>  * unrolling the normal 16 bits at a time loop eight times.
>> Even
>> @@ -216,7 +216,7 @@ static inline int
>> odph_process_l3_hdr(odp_packet_t odp_pkt,
>> ipv6_hdr_ptr = _hdr;
>> }
>>
>> -   addrs_ptr= (uint16_t *)_hdr_ptr->src_addr;
>> +   addrs_ptr= (uint16_t *)(void
>> *)_hdr_ptr->src_addr;
>> addrs_len= 2 * ODPH_IPV6ADDR_LEN;
>> protocol = ipv6_hdr_ptr->next_hdr;
>> ipv6_payload_len =
>> odp_be_to_cpu_16(ipv6_hdr_ptr->payload_len);
>> diff --git a/helper/hashtable.c b/helper/hashtable.c
>> index 8bb1ae5..0b652b3 100644
>> --- a/helper/hashtable.c
>> +++ b/helper/hashtable.c
>> @@ -101,9 +101,9 @@ odph_table_t odph_hash_table_create(const char
>> *name, uint32_t capacity,
>>  * the last part is the element node pool
>>  */
>>
>> -   tbl->lock_pool = (odp_rwlock_t *)((char *)tbl
>> +   tbl->lock_pool = (odp_rwlock_t *)(void *)((char *)tbl
>> + sizeof(odph_hash_table_imp));
>> -   tbl->list_head_pool = (odph_list_head *)((char *)tbl->lock_pool
>> +   tbl->list_head_pool = (odph_list_head *)(void *)((char
>> *)tbl->lock_pool
>> + ODPH_MAX_BUCKET_NUM * sizeof(odp_rwlock_t));
>>
>> node_mem = tbl->init_cap - sizeof(odph_hash_table_imp)
>> @@ -112,8 +112,9 @@ odph_table_t odph_hash_table_create(const char
>>

Re: [lng-odp] 32-bit support in examples

2017-01-20 Thread Brian Brooks

CAS is a universal primitive in the sense that you can construct those
RMW ops by speculatively computing the updated value and the CAS to
atomically update the value (in a retry loop).  LL/SC also universal,
but different behavior.  Both are not the same as an atomic op
performed deeper in the memory system.

To Petri's point about ODP not supporting 128b atomics, which compiler
does not support the __atomic_xxx built-ins or the __int128 128b
variable?  This has impact on portability and should be explicitly
known; is it the microblaze compiler?

On Fri, Jan 20, 2017 at 7:36 AM, Francois Ozog  wrote:
> well, yes. But that is the only atomic operation supported. No add, sub,
> inc, xadd, bit operations
>
> Le ven. 20 janv. 2017 à 14:31, Joe Savage  a écrit :
>
>> > I wonder what processor supports 128 bits atomics. As far as I know Intel
>>
>> > does not support it. Lock prefix is not allowed on SSE instructions.
>>
>>
>>
>> Actually, Intel does support them through a locked cmpxchg16b. And ARMv8
>>
>> through load exclusive pair and store exclusive pair.
>>
>>

Re: [lng-odp] [API-NEXT PATCH 1/4] api: timer: add odp_timer_capability() api

2017-01-20 Thread Mike Holmes

Hi Kevin

How did you send these patches ?
If you look in patchworks it can't identify them as a series and gives
them odd names. http://patches.opendataplane.org/project/lng-odp/list/

Untitled series #10
Untitled series #11
Untitled series #12

Even though they claim to be (n) of 4

Perhaps you did not generate them with git format patch as a series
but manually changed their names ?

Mike

On 20 January 2017 at 00:21, Kevin Wang  wrote:
> Currently, user needs to decide the timer resolution before creating
> a timer pool. But sometimes it will cause timer overrun as the system
> can't support such high resolution.
> So a new API is required to expose the timer capability to the user.
>
> Signed-off-by: Kevin Wang 
> ---
>  include/odp/api/spec/timer.h | 21 +
>  1 file changed, 21 insertions(+)
>
> diff --git a/include/odp/api/spec/timer.h b/include/odp/api/spec/timer.h
> index 75f9db9..78d9119 100644
> --- a/include/odp/api/spec/timer.h
> +++ b/include/odp/api/spec/timer.h
> @@ -108,6 +108,27 @@ typedef struct {
>  } odp_timer_pool_param_t;
>
>  /**
> + * Timer capability
> + */
> +typedef struct {
> +   uint64_t res_ns; /**< Timeout resolution in nanoseconds */
> +} odp_timer_capability_t;
> +
> +
> +/**
> + * Query Timer interface capabilities
> + *
> + * Outputs Timer interface capabilities on success.
> + *
> + * @param clk_src Clock source for timers
> + * @param[out] capa   Pointer to capability structure for output
> + *
> + * @retval 0 on success
> + * @retval <0 on failure
> + */
> +int odp_timer_capability(odp_timer_clk_src_t clk_src, odp_timer_capability_t 
> *capa);
> +
> +/**
>   * Create a timer pool
>   *
>   * The use of pool name is optional. Unique names are not required.
> --
> 1.9.1
>



-- 
Mike Holmes
Program Manager - Linaro Networking Group
Linaro.org │ Open source software for ARM SoCs
"Work should be fun and collaborative, the rest follows"

Re: [lng-odp] [PATCH] linux-gen: _ishm: checking fstat return value.

2017-01-20 Thread Mike Holmes

On 20 January 2017 at 11:40, Christophe Milard
 wrote:
> Hence fixing CID 174663

Adding:

Fixes https://bugs.linaro.org/show_bug.cgi?id=2827

Makes it easy to track closing a bug

>
> Signed-off-by: Christophe Milard 
> ---
>  platform/linux-generic/_ishm.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/platform/linux-generic/_ishm.c b/platform/linux-generic/_ishm.c
> index f889834..8da64a1 100644
> --- a/platform/linux-generic/_ishm.c
> +++ b/platform/linux-generic/_ishm.c
> @@ -818,7 +818,12 @@ int _odp_ishm_reserve(const char *name, uint64_t size, 
> int fd,
>
> /* If a file descriptor is provided, get the real size and map: */
> if (fd >= 0) {
> -   fstat(fd, );
> +   if (fstat(fd, ) < 0) {
> +   close(fd);
> +   odp_spinlock_unlock(_tbl->lock);
> +   ODP_ERR("_ishm_reserve failed (fstat failed).\n");
> +   return -1;
> +   }
> len = statbuf.st_size;
> /* note that the huge page flag is meningless here as huge
>  * page is determined by the provided file descriptor: */
> --
> 2.7.4
>



-- 
Mike Holmes
Program Manager - Linaro Networking Group
Linaro.org │ Open source software for ARM SoCs
"Work should be fun and collaborative, the rest follows"

Re: [lng-odp] [PATCH v2 1/2] linux-gen: netmap: fix interface flags initialization

2017-01-20 Thread Maxim Uvarov

On 01/09/17 13:56, Matias Elo wrote:
> Previously netmap interface flags parsed by nm_open() were always
> overwritten by netmap_start() function. In netmap v11.2 release this breaks
> pipe interface initialization. Fix this by setting the netmap flags only
> when needed.
> 
> Signed-off-by: Matias Elo 
> ---
>  platform/linux-generic/pktio/netmap.c | 37 
> +++
>  1 file changed, 25 insertions(+), 12 deletions(-)
> 
> diff --git a/platform/linux-generic/pktio/netmap.c 
> b/platform/linux-generic/pktio/netmap.c
> index 412beec..1c42937 100644
> --- a/platform/linux-generic/pktio/netmap.c
> +++ b/platform/linux-generic/pktio/netmap.c
> @@ -454,7 +454,7 @@ static int netmap_start(pktio_entry_t *pktio_entry)
>  {
>   pkt_netmap_t *pkt_nm = _entry->s.pkt_nm;
>   netmap_ring_t *desc_ring;
> - struct nm_desc base_desc;
> + struct nm_desc *desc_ptr;
>   unsigned i;
>   unsigned j;
>   unsigned num_rx_desc = 0;
> @@ -505,18 +505,27 @@ static int netmap_start(pktio_entry_t *pktio_entry)
>pktio_entry->s.num_out_queue,
>pktio_entry->s.num_out_queue);
>  
> - memset(_desc, 0, sizeof(struct nm_desc));
> + /* Use nm_open() to parse netmap flags from interface name */
> + desc_ptr = nm_open(pkt_nm->nm_name, NULL, 0, NULL);
> + if (desc_ptr == NULL) {
> + ODP_ERR("nm_start(%s) failed\n", pkt_nm->nm_name);
> + goto error;
> + }
> + struct nm_desc base_desc = *desc_ptr;
> +

code style: struct declaration has to be on top of function.



> + nm_close(desc_ptr);
> +
>   base_desc.self = _desc;
>   base_desc.mem = NULL;
> - memcpy(base_desc.req.nr_name, pkt_nm->if_name, sizeof(pkt_nm->if_name));
> - base_desc.req.nr_flags &= ~NR_REG_MASK;
> -
> - if (num_rx_desc == 1)
> - base_desc.req.nr_flags |= NR_REG_ALL_NIC;
> - else
> - base_desc.req.nr_flags |= NR_REG_ONE_NIC;
> -
>   base_desc.req.nr_ringid = 0;
> + if ((base_desc.req.nr_flags & NR_REG_MASK) == NR_REG_ALL_NIC ||
> + (base_desc.req.nr_flags & NR_REG_MASK) == NR_REG_ONE_NIC) {
> + base_desc.req.nr_flags &= ~NR_REG_MASK;
> + if (num_rx_desc == 1)
> + base_desc.req.nr_flags |= NR_REG_ALL_NIC;
> + else
> + base_desc.req.nr_flags |= NR_REG_ONE_NIC;
> + }
>  
>   /* Only the first rx descriptor does mmap */
>   desc_ring = pkt_nm->rx_desc_ring;
> @@ -550,8 +559,12 @@ static int netmap_start(pktio_entry_t *pktio_entry)
>   /* Open tx descriptors */
>   desc_ring = pkt_nm->tx_desc_ring;
>   flags = NM_OPEN_IFNAME | NM_OPEN_NO_MMAP;
> - base_desc.req.nr_flags &= ~NR_REG_ALL_NIC;
> - base_desc.req.nr_flags |= NR_REG_ONE_NIC;
> +
> + if ((base_desc.req.nr_flags & NR_REG_MASK) == NR_REG_ALL_NIC) {
> + base_desc.req.nr_flags &= ~NR_REG_ALL_NIC;
> + base_desc.req.nr_flags |= NR_REG_ONE_NIC;
> + }
> +
>   for (i = 0; i < pktio_entry->s.num_out_queue; i++) {
>   for (j = desc_ring[i].s.first; j <= desc_ring[i].s.last; j++) {
>   base_desc.req.nr_ringid = j;
>

Re: [lng-odp] [PATCH v2 1/2] linux-gen: align: round up power of two as macro

2017-01-20 Thread Bill Fischofer

On Fri, Jan 20, 2017 at 4:28 AM, Yi He  wrote:
> For this patch series, I've reviewed and tested good against master branch:
>
> Reviewed-and-tested-by: Yi He 
>
> On api-next branch it encounters compilation error, what's our typical
> solution for this kind of problem?
> _ishmpool.c:209:3: error: implicit declaration of function ‘
> ODP_CACHE_LINE_SIZE_ROUNDUP’
>
> Best Regards, Yi

Yi, this is normally handled as part of the back-merge into api-next.
This is against master so as long as it applies and builds there it's
fine.


>
> On 20 January 2017 at 17:14, Petri Savolainen 
> wrote:
>
>> Implement round up to power of two as a macro. Macro
>> enables preprocessor to calculate the constant value and
>> avoid code generation. Also dependency to __builtin_clz()
>> is not needed anymore.
>>
>> Signed-off-by: Petri Savolainen 
>> ---
>>  .../linux-generic/include/odp_align_internal.h | 26
>> +++---
>>  platform/linux-generic/odp_pool.c  |  2 +-
>>  platform/linux-generic/odp_schedule_sp.c   |  2 +-
>>  3 files changed, 20 insertions(+), 10 deletions(-)
>>
>> diff --git a/platform/linux-generic/include/odp_align_internal.h
>> b/platform/linux-generic/include/odp_align_internal.h
>> index d9cd30b..e5b2f37 100644
>> --- a/platform/linux-generic/include/odp_align_internal.h
>> +++ b/platform/linux-generic/include/odp_align_internal.h
>> @@ -18,6 +18,7 @@ extern "C" {
>>  #endif
>>
>>  #include 
>> +#include 
>>
>>  /** @addtogroup odp_compiler_optim
>>   *  @{
>> @@ -27,6 +28,23 @@ extern "C" {
>>   * Round up
>>   */
>>
>> +/* Macros to calculate ODP_ROUNDUP_POWER2_U32() in five rounds of shift
>> + * and OR operations. */
>> +#define _RSHIFT_U32(x, y) (((uint32_t)(x)) >> (y))
>> +#define _POW2_U32_R1(x)   (((uint32_t)(x)) | _RSHIFT_U32(x, 1))
>> +#define _POW2_U32_R2(x)   (_POW2_U32_R1(x) | _RSHIFT_U32(_POW2_U32_R1(x),
>> 2))
>> +#define _POW2_U32_R3(x)   (_POW2_U32_R2(x) | _RSHIFT_U32(_POW2_U32_R2(x),
>> 4))
>> +#define _POW2_U32_R4(x)   (_POW2_U32_R3(x) | _RSHIFT_U32(_POW2_U32_R3(x),
>> 8))
>> +#define _POW2_U32_R5(x)   (_POW2_U32_R4(x) | _RSHIFT_U32(_POW2_U32_R4(x),
>> 16))
>> +
>> +/* Round up a uint32_t value 'x' to the next power of two.
>> + *
>> + * The value is not round up, if it's already a power of two (including
>> 1).
>> + * The value must be larger than 0 and not exceed 0x8000.
>> + */
>> +#define ODP_ROUNDUP_POWER2_U32(x) \
>> +   uint32_t)(x)) > 0x8000) ? 0 : (_POW2_U32_R5(x - 1) + 1))
>> +
>>  /**
>>   * @internal
>>   * Round up 'x' to alignment 'align'
>> @@ -36,14 +54,6 @@ extern "C" {
>>
>>  /**
>>   * @internal
>> - * When 'x' is not already a power of two, round it up to the next
>> - * power of two value. Zero is not supported as an input value.
>> - */
>> -#define ODP_ROUNDUP_POWER_2(x)\
>> -   (1 << (((int)(8 * sizeof(x))) - __builtin_clz((x) - 1)))
>> -
>> -/**
>> - * @internal
>>   * Round up pointer 'x' to alignment 'align'
>>   */
>>  #define ODP_ALIGN_ROUNDUP_PTR(x, align)\
>> diff --git a/platform/linux-generic/odp_pool.c
>> b/platform/linux-generic/odp_pool.c
>> index 090a55f..0d12d0b 100644
>> --- a/platform/linux-generic/odp_pool.c
>> +++ b/platform/linux-generic/odp_pool.c
>> @@ -381,7 +381,7 @@ static odp_pool_t pool_create(const char *name,
>> odp_pool_param_t *params,
>> if (num <= RING_SIZE_MIN)
>> ring_size = RING_SIZE_MIN;
>> else
>> -   ring_size = ODP_ROUNDUP_POWER_2(num);
>> +   ring_size = ODP_ROUNDUP_POWER2_U32(num);
>>
>> pool->ring_mask  = ring_size - 1;
>> pool->num= num;
>> diff --git a/platform/linux-generic/odp_schedule_sp.c
>> b/platform/linux-generic/odp_schedule_sp.c
>> index 5150d28..5ccd32d 100644
>> --- a/platform/linux-generic/odp_schedule_sp.c
>> +++ b/platform/linux-generic/odp_schedule_sp.c
>> @@ -34,7 +34,7 @@
>>  #define GROUP_PKTIN   GROUP_ALL
>>
>>  /* Maximum number of commands: one priority/group for all queues and
>> pktios */
>> -#define RING_SIZE (ODP_ROUNDUP_POWER_2(NUM_QUEUE + NUM_PKTIO))
>> +#define RING_SIZE (ODP_ROUNDUP_POWER2_U32(NUM_QUEUE + NUM_PKTIO))
>>  #define RING_MASK (RING_SIZE - 1)
>>
>>  /* Ring size must be power of two */
>> --
>> 2.8.1
>>
>>

Re: [lng-odp] [PATCH v2 1/2] linux-gen: align: round up power of two as macro

2017-01-20 Thread Bill Fischofer

For the v2 series:

Reviewed-and-tested-by: Bill Fischofer 

On Fri, Jan 20, 2017 at 3:14 AM, Petri Savolainen
 wrote:
> Implement round up to power of two as a macro. Macro
> enables preprocessor to calculate the constant value and
> avoid code generation. Also dependency to __builtin_clz()
> is not needed anymore.
>
> Signed-off-by: Petri Savolainen 
> ---
>  .../linux-generic/include/odp_align_internal.h | 26 
> +++---
>  platform/linux-generic/odp_pool.c  |  2 +-
>  platform/linux-generic/odp_schedule_sp.c   |  2 +-
>  3 files changed, 20 insertions(+), 10 deletions(-)
>
> diff --git a/platform/linux-generic/include/odp_align_internal.h 
> b/platform/linux-generic/include/odp_align_internal.h
> index d9cd30b..e5b2f37 100644
> --- a/platform/linux-generic/include/odp_align_internal.h
> +++ b/platform/linux-generic/include/odp_align_internal.h
> @@ -18,6 +18,7 @@ extern "C" {
>  #endif
>
>  #include 
> +#include 
>
>  /** @addtogroup odp_compiler_optim
>   *  @{
> @@ -27,6 +28,23 @@ extern "C" {
>   * Round up
>   */
>
> +/* Macros to calculate ODP_ROUNDUP_POWER2_U32() in five rounds of shift
> + * and OR operations. */
> +#define _RSHIFT_U32(x, y) (((uint32_t)(x)) >> (y))
> +#define _POW2_U32_R1(x)   (((uint32_t)(x)) | _RSHIFT_U32(x, 1))
> +#define _POW2_U32_R2(x)   (_POW2_U32_R1(x) | _RSHIFT_U32(_POW2_U32_R1(x), 2))
> +#define _POW2_U32_R3(x)   (_POW2_U32_R2(x) | _RSHIFT_U32(_POW2_U32_R2(x), 4))
> +#define _POW2_U32_R4(x)   (_POW2_U32_R3(x) | _RSHIFT_U32(_POW2_U32_R3(x), 8))
> +#define _POW2_U32_R5(x)   (_POW2_U32_R4(x) | _RSHIFT_U32(_POW2_U32_R4(x), 
> 16))
> +
> +/* Round up a uint32_t value 'x' to the next power of two.
> + *
> + * The value is not round up, if it's already a power of two (including 1).
> + * The value must be larger than 0 and not exceed 0x8000.
> + */
> +#define ODP_ROUNDUP_POWER2_U32(x) \
> +   uint32_t)(x)) > 0x8000) ? 0 : (_POW2_U32_R5(x - 1) + 1))
> +
>  /**
>   * @internal
>   * Round up 'x' to alignment 'align'
> @@ -36,14 +54,6 @@ extern "C" {
>
>  /**
>   * @internal
> - * When 'x' is not already a power of two, round it up to the next
> - * power of two value. Zero is not supported as an input value.
> - */
> -#define ODP_ROUNDUP_POWER_2(x)\
> -   (1 << (((int)(8 * sizeof(x))) - __builtin_clz((x) - 1)))
> -
> -/**
> - * @internal
>   * Round up pointer 'x' to alignment 'align'
>   */
>  #define ODP_ALIGN_ROUNDUP_PTR(x, align)\
> diff --git a/platform/linux-generic/odp_pool.c 
> b/platform/linux-generic/odp_pool.c
> index 090a55f..0d12d0b 100644
> --- a/platform/linux-generic/odp_pool.c
> +++ b/platform/linux-generic/odp_pool.c
> @@ -381,7 +381,7 @@ static odp_pool_t pool_create(const char *name, 
> odp_pool_param_t *params,
> if (num <= RING_SIZE_MIN)
> ring_size = RING_SIZE_MIN;
> else
> -   ring_size = ODP_ROUNDUP_POWER_2(num);
> +   ring_size = ODP_ROUNDUP_POWER2_U32(num);
>
> pool->ring_mask  = ring_size - 1;
> pool->num= num;
> diff --git a/platform/linux-generic/odp_schedule_sp.c 
> b/platform/linux-generic/odp_schedule_sp.c
> index 5150d28..5ccd32d 100644
> --- a/platform/linux-generic/odp_schedule_sp.c
> +++ b/platform/linux-generic/odp_schedule_sp.c
> @@ -34,7 +34,7 @@
>  #define GROUP_PKTIN   GROUP_ALL
>
>  /* Maximum number of commands: one priority/group for all queues and pktios 
> */
> -#define RING_SIZE (ODP_ROUNDUP_POWER_2(NUM_QUEUE + NUM_PKTIO))
> +#define RING_SIZE (ODP_ROUNDUP_POWER2_U32(NUM_QUEUE + NUM_PKTIO))
>  #define RING_MASK (RING_SIZE - 1)
>
>  /* Ring size must be power of two */
> --
> 2.8.1
>

Re: [lng-odp] [PATCH 0/8] First ABI files

2017-01-20 Thread Bill Fischofer

On Fri, Jan 20, 2017 at 8:22 AM, Savolainen, Petri (Nokia - FI/Espoo)
 wrote:
>
>
>> -Original Message-
>> From: Bill Fischofer [mailto:bill.fischo...@linaro.org]
>> Sent: Friday, January 20, 2017 4:13 PM
>> To: Savolainen, Petri (Nokia - FI/Espoo) > labs.com>
>> Cc: lng-odp-forward 
>> Subject: Re: [lng-odp] [PATCH 0/8] First ABI files
>>
>> On Fri, Jan 20, 2017 at 3:33 AM, Savolainen, Petri (Nokia - FI/Espoo)
>>  wrote:
>> >> -Original Message-
>> >> From: Bill Fischofer [mailto:bill.fischo...@linaro.org]
>> >> Sent: Thursday, January 19, 2017 11:53 PM
>> >> To: Savolainen, Petri (Nokia - FI/Espoo) > >> labs.com>
>> >> Cc: lng-odp-forward 
>> >> Subject: Re: [lng-odp] [PATCH 0/8] First ABI files
>> >>
>> >> This series represents a significant structural change and as such
>> >> should go against api-next, not master. Patches aimed at master should
>> >> be bug fixes, not something that introduces new structure development.
>> >
>> >
>> > I think we should stop right here of doing "significant changes" through
>> api-next. Last time that policy effectively stopped the work in master due
>> to dependencies over many files changed. Api-next should be reserved only
>> for API spec changing modifications, since only those are visible to
>> applications. E.g. changes in ABI does not require any application change.
>> Today our "ABI" support is non-existent. This sets ground work for files
>> and Makefiles to enable ABI(s) and force that.
>> >
>> >
>> >>
>> >> While the goals here seem good, I'm concerned that at this stage
>> >> applying this removes strong typing support. For example, as an
>> >> experiment I changed the buffer validation test to contain this error:
>> >
>> > I'll look into strong typing as default. But vendors may very well agree
>> not to support it, since it requires handles to be pointer size types.
>> E.g. arm64 ABI may be agreed to use uint32_t for handles instead of
>> pointers.
>> >
>>
>> Are there many storage-constrained 64-bit systems? For 32-bit embedded
>> environments pointers are already 4 bytes, so this shouldn't be a
>> problem. Since handles are opaque, the only thing that's needed for
>> ABI compatibility is that there is common agreement on their size
>> since application code never manipulates the structure of any
>> handle--that's all done in each implementation.
>>
>> This is another reason to have internal vs. external handles as we
>> discussed earlier with Honnappa. The strong typing is most important
>> on the external handles since they are part of the API spec even if
>> the details are left to each implementation. Implementations can
>> choose to relax this if they want more compact handles for internal
>> use.
>
> The excessive storage size is the main issue here. E.g. if all handles are 8 
> bytes instead of 4 bytes, an application need to reserve 2x memory for the 
> same number of those. With double memory space both total memory consumption 
> may increase too high and more likely performance is lower due to less 
> handles fitting various cache levels.
>
> Also not all handles need to be 8 bytes of space. E.g. packet seg handle can 
> be a small integer since those are few and those depend on a packet handle, 
> etc.

I agree, however it's a deficiency in the C type system that there
doesn't appear to be any other way to achieve strong typing than the
one we settled on. A native C++ ODP API would have more options since
types in C++ are strong by default. There's also the question of C
language level. At the time we started this project it was felt that
C11 was "too new" to require, which is why we settled on C99. If it's
OK to reconsider C11 we might be able to improve on the current
techniques. Something to discuss?

>
> -Petri
>
>

Re: [lng-odp] [PATCH 0/8] First ABI files

2017-01-20 Thread Savolainen, Petri (Nokia - FI/Espoo)



> -Original Message-
> From: Bill Fischofer [mailto:bill.fischo...@linaro.org]
> Sent: Friday, January 20, 2017 4:13 PM
> To: Savolainen, Petri (Nokia - FI/Espoo)  labs.com>
> Cc: lng-odp-forward 
> Subject: Re: [lng-odp] [PATCH 0/8] First ABI files
> 
> On Fri, Jan 20, 2017 at 3:33 AM, Savolainen, Petri (Nokia - FI/Espoo)
>  wrote:
> >> -Original Message-
> >> From: Bill Fischofer [mailto:bill.fischo...@linaro.org]
> >> Sent: Thursday, January 19, 2017 11:53 PM
> >> To: Savolainen, Petri (Nokia - FI/Espoo)  >> labs.com>
> >> Cc: lng-odp-forward 
> >> Subject: Re: [lng-odp] [PATCH 0/8] First ABI files
> >>
> >> This series represents a significant structural change and as such
> >> should go against api-next, not master. Patches aimed at master should
> >> be bug fixes, not something that introduces new structure development.
> >
> >
> > I think we should stop right here of doing "significant changes" through
> api-next. Last time that policy effectively stopped the work in master due
> to dependencies over many files changed. Api-next should be reserved only
> for API spec changing modifications, since only those are visible to
> applications. E.g. changes in ABI does not require any application change.
> Today our "ABI" support is non-existent. This sets ground work for files
> and Makefiles to enable ABI(s) and force that.
> >
> >
> >>
> >> While the goals here seem good, I'm concerned that at this stage
> >> applying this removes strong typing support. For example, as an
> >> experiment I changed the buffer validation test to contain this error:
> >
> > I'll look into strong typing as default. But vendors may very well agree
> not to support it, since it requires handles to be pointer size types.
> E.g. arm64 ABI may be agreed to use uint32_t for handles instead of
> pointers.
> >
> 
> Are there many storage-constrained 64-bit systems? For 32-bit embedded
> environments pointers are already 4 bytes, so this shouldn't be a
> problem. Since handles are opaque, the only thing that's needed for
> ABI compatibility is that there is common agreement on their size
> since application code never manipulates the structure of any
> handle--that's all done in each implementation.
> 
> This is another reason to have internal vs. external handles as we
> discussed earlier with Honnappa. The strong typing is most important
> on the external handles since they are part of the API spec even if
> the details are left to each implementation. Implementations can
> choose to relax this if they want more compact handles for internal
> use.

The excessive storage size is the main issue here. E.g. if all handles are 8 
bytes instead of 4 bytes, an application need to reserve 2x memory for the same 
number of those. With double memory space both total memory consumption may 
increase too high and more likely performance is lower due to less handles 
fitting various cache levels.
 
Also not all handles need to be 8 bytes of space. E.g. packet seg handle can be 
a small integer since those are few and those depend on a packet handle, etc.

-Petri

Re: [lng-odp] [PATCH 0/8] First ABI files

2017-01-20 Thread Bill Fischofer

On Fri, Jan 20, 2017 at 3:33 AM, Savolainen, Petri (Nokia - FI/Espoo)
 wrote:
>> -Original Message-
>> From: Bill Fischofer [mailto:bill.fischo...@linaro.org]
>> Sent: Thursday, January 19, 2017 11:53 PM
>> To: Savolainen, Petri (Nokia - FI/Espoo) > labs.com>
>> Cc: lng-odp-forward 
>> Subject: Re: [lng-odp] [PATCH 0/8] First ABI files
>>
>> This series represents a significant structural change and as such
>> should go against api-next, not master. Patches aimed at master should
>> be bug fixes, not something that introduces new structure development.
>
>
> I think we should stop right here of doing "significant changes" through 
> api-next. Last time that policy effectively stopped the work in master due to 
> dependencies over many files changed. Api-next should be reserved only for 
> API spec changing modifications, since only those are visible to 
> applications. E.g. changes in ABI does not require any application change. 
> Today our "ABI" support is non-existent. This sets ground work for files and 
> Makefiles to enable ABI(s) and force that.
>
>
>>
>> While the goals here seem good, I'm concerned that at this stage
>> applying this removes strong typing support. For example, as an
>> experiment I changed the buffer validation test to contain this error:
>
> I'll look into strong typing as default. But vendors may very well agree not 
> to support it, since it requires handles to be pointer size types. E.g. arm64 
> ABI may be agreed to use uint32_t for handles instead of pointers.
>

Are there many storage-constrained 64-bit systems? For 32-bit embedded
environments pointers are already 4 bytes, so this shouldn't be a
problem. Since handles are opaque, the only thing that's needed for
ABI compatibility is that there is common agreement on their size
since application code never manipulates the structure of any
handle--that's all done in each implementation.

This is another reason to have internal vs. external handles as we
discussed earlier with Honnappa. The strong typing is most important
on the external handles since they are part of the API spec even if
the details are left to each implementation. Implementations can
choose to relax this if they want more compact handles for internal
use.

> -Petri

[lng-odp] [PATCH v2 3/8] abi: classifier: added initial definitions

2017-01-20 Thread Petri Savolainen

Initially, use the same default ABI file for all architectures.
Default values match those defined in odp-linux implementation
to minimize changes in this phase. Removed unused type
definitions, documentation of those need to be still removed
for API spec.

Signed-off-by: Petri Savolainen 
---
 .../arch/arm32-linux/odp/api/abi/classification.h  |  7 
 .../arch/arm64-linux/odp/api/abi/classification.h  |  7 
 include/odp/arch/default/api/abi/classification.h  | 40 ++
 .../arch/mips64-linux/odp/api/abi/classification.h |  7 
 .../power64-linux/odp/api/abi/classification.h |  7 
 .../arch/x86_32-linux/odp/api/abi/classification.h |  7 
 .../arch/x86_64-linux/odp/api/abi/classification.h |  7 
 platform/Makefile.inc  |  2 ++
 .../linux-generic/include/odp/api/classification.h |  9 +++--
 .../include/odp/api/plat/classification_types.h| 34 +++---
 .../include/odp_classification_datamodel.h |  3 --
 platform/linux-generic/odp_classification.c| 12 +--
 12 files changed, 114 insertions(+), 28 deletions(-)
 create mode 100644 include/odp/arch/arm32-linux/odp/api/abi/classification.h
 create mode 100644 include/odp/arch/arm64-linux/odp/api/abi/classification.h
 create mode 100644 include/odp/arch/default/api/abi/classification.h
 create mode 100644 include/odp/arch/mips64-linux/odp/api/abi/classification.h
 create mode 100644 include/odp/arch/power64-linux/odp/api/abi/classification.h
 create mode 100644 include/odp/arch/x86_32-linux/odp/api/abi/classification.h
 create mode 100644 include/odp/arch/x86_64-linux/odp/api/abi/classification.h

diff --git a/include/odp/arch/arm32-linux/odp/api/abi/classification.h 
b/include/odp/arch/arm32-linux/odp/api/abi/classification.h
new file mode 100644
index 000..d48a473
--- /dev/null
+++ b/include/odp/arch/arm32-linux/odp/api/abi/classification.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/arm64-linux/odp/api/abi/classification.h 
b/include/odp/arch/arm64-linux/odp/api/abi/classification.h
new file mode 100644
index 000..d48a473
--- /dev/null
+++ b/include/odp/arch/arm64-linux/odp/api/abi/classification.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/default/api/abi/classification.h 
b/include/odp/arch/default/api/abi/classification.h
new file mode 100644
index 000..771907a
--- /dev/null
+++ b/include/odp/arch/default/api/abi/classification.h
@@ -0,0 +1,40 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#ifndef ODP_ABI_CLASSIFICATION_H_
+#define ODP_ABI_CLASSIFICATION_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/** @internal Dummy type for strong typing */
+typedef struct { char dummy; /**< @internal Dummy */ } _odp_abi_cos_t;
+
+/** Dummy type for strong typing */
+typedef struct { char dummy; /**< @internal Dummy */ } _odp_abi_pmr_t;
+
+/** @ingroup odp_classification
+ *  @{
+ */
+
+typedef _odp_abi_cos_t *odp_cos_t;
+typedef _odp_abi_pmr_t *odp_pmr_t;
+
+#define ODP_COS_INVALID   ((odp_cos_t)~0)
+#define ODP_PMR_INVAL ((odp_pmr_t)~0)
+
+#define ODP_COS_NAME_LEN  32
+
+/**
+ * @}
+ */
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif
diff --git a/include/odp/arch/mips64-linux/odp/api/abi/classification.h 
b/include/odp/arch/mips64-linux/odp/api/abi/classification.h
new file mode 100644
index 000..d48a473
--- /dev/null
+++ b/include/odp/arch/mips64-linux/odp/api/abi/classification.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/power64-linux/odp/api/abi/classification.h 
b/include/odp/arch/power64-linux/odp/api/abi/classification.h
new file mode 100644
index 000..d48a473
--- /dev/null
+++ b/include/odp/arch/power64-linux/odp/api/abi/classification.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/x86_32-linux/odp/api/abi/classification.h 
b/include/odp/arch/x86_32-linux/odp/api/abi/classification.h
new file mode 100644
index 000..d48a473
--- /dev/null
+++ b/include/odp/arch/x86_32-linux/odp/api/abi/classification.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/x86_64-linux/odp/api/abi/classification.h 
b/include/odp/arch/x86_64-linux/odp/api/abi/classification.h
new file mode 100644
index 000..d48a473
--- /dev/null
+++ b/include/odp/arch/x86_64-linux/odp/api/abi/classification.h
@@

[lng-odp] [PATCH v2 1/8] abi: event: added the first ABI spec file

2017-01-20 Thread Petri Savolainen

Used event API as the first example of an ABI spec file. Used
the same default architecture file initially for all
architectures. Default ABI files avoid multiple copies
of the same definition.

Signed-off-by: Petri Savolainen 
---
 configure.ac   | 22 
 example/Makefile.inc   |  1 +
 helper/Makefile.am |  1 +
 include/odp/arch/arm32-linux/odp/api/abi/event.h   |  7 
 include/odp/arch/arm64-linux/odp/api/abi/event.h   |  7 
 include/odp/arch/default/api/abi/event.h   | 42 ++
 include/odp/arch/mips64-linux/odp/api/abi/event.h  |  7 
 include/odp/arch/power64-linux/odp/api/abi/event.h |  7 
 include/odp/arch/x86_32-linux/odp/api/abi/event.h  |  7 
 include/odp/arch/x86_64-linux/odp/api/abi/event.h  |  7 
 platform/Makefile.inc  |  8 +
 platform/linux-generic/Makefile.am |  1 +
 .../include/odp/api/plat/event_types.h | 19 +-
 platform/linux-generic/odp_event.c |  5 +++
 test/Makefile.inc  |  1 +
 test/linux-generic/Makefile.inc|  1 +
 16 files changed, 132 insertions(+), 11 deletions(-)
 create mode 100644 include/odp/arch/arm32-linux/odp/api/abi/event.h
 create mode 100644 include/odp/arch/arm64-linux/odp/api/abi/event.h
 create mode 100644 include/odp/arch/default/api/abi/event.h
 create mode 100644 include/odp/arch/mips64-linux/odp/api/abi/event.h
 create mode 100644 include/odp/arch/power64-linux/odp/api/abi/event.h
 create mode 100644 include/odp/arch/x86_32-linux/odp/api/abi/event.h
 create mode 100644 include/odp/arch/x86_64-linux/odp/api/abi/event.h

diff --git a/configure.ac b/configure.ac
index 67d60d2..b3f016c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -119,6 +119,26 @@ then
 fi
 
 ##
+# Architecture for ABI support
+##
+AS_CASE([$host],
+  [x86*], [ARCH_ABI=x86_64-linux],
+  [i686*],[ARCH_ABI=x86_32-linux],
+  [mips64*],  [ARCH_ABI=mips64-linux],
+  [powerpc*], [ARCH_ABI=power64-linux],
+  [aarch64*], [ARCH_ABI=arm64-linux],
+  [arm*], [ARCH_ABI=arm32-linux],
+  [ARCH_ABI=undefined]
+)
+AC_SUBST([ARCH_ABI])
+
+if test "${ARCH_ABI}" == "undefined";
+then
+echo "ARCH_ABI is undefined, please add your ARCH_ABI based on 
host=${host}"
+exit 1
+fi
+
+##
 # Set correct pkgconfig version
 ##
 PKGCONFIG_VERSION=$(echo $VERSION | awk -F '.git' '{print $1}')
@@ -322,7 +342,9 @@ AC_MSG_RESULT([
Helper Library version: ${ODPHELPER_LIBSO_VERSION}
 
implementation_name:${IMPLEMENTATION_NAME}
+   host:   ${host}
ARCH_DIR${ARCH_DIR}
+   ARCH_ABI${ARCH_ABI}
with_platform:  ${with_platform}
prefix: ${prefix}
sysconfdir: ${sysconfdir}
diff --git a/example/Makefile.inc b/example/Makefile.inc
index 19d3994..a52e40c 100644
--- a/example/Makefile.inc
+++ b/example/Makefile.inc
@@ -6,6 +6,7 @@ AM_CFLAGS += \
-I$(top_srcdir)/example \
-I$(top_srcdir)/platform/@with_platform@/include \
-I$(top_srcdir)/include/ \
+   -I$(top_srcdir)/include/odp/arch/@ARCH_ABI@ \
-I$(top_srcdir)/helper/include \
-I$(top_builddir)/platform/@with_platform@/include \
-I$(top_builddir)/include
diff --git a/helper/Makefile.am b/helper/Makefile.am
index 9d0036d..badbbf8 100644
--- a/helper/Makefile.am
+++ b/helper/Makefile.am
@@ -7,6 +7,7 @@ LIB   = $(top_builddir)/lib
 AM_CFLAGS  = -I$(srcdir)/include
 AM_CFLAGS += -I$(top_srcdir)/platform/@with_platform@/include
 AM_CFLAGS += -I$(top_srcdir)/include
+AM_CFLAGS += -I$(top_srcdir)/include/odp/arch/@ARCH_ABI@
 AM_CFLAGS += -I$(top_builddir)/platform/@with_platform@/include
 AM_CFLAGS += -I$(top_builddir)/include
 
diff --git a/include/odp/arch/arm32-linux/odp/api/abi/event.h 
b/include/odp/arch/arm32-linux/odp/api/abi/event.h
new file mode 100644
index 000..5d2ac75
--- /dev/null
+++ b/include/odp/arch/arm32-linux/odp/api/abi/event.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/arm64-linux/odp/api/abi/event.h 
b/include/odp/arch/arm64-linux/odp/api/abi/event.h
new file mode 100644
index 000..5d2ac75
--- /dev/null
+++ b/include/odp/arch/arm64-linux/odp/api/abi/event.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git

[lng-odp] [PATCH v2 0/8] First ABI files

2017-01-20 Thread Petri Savolainen

Added initial version of couple of ABI specification files. These files define 
types/values that are implementation specific in the API spec. For ABI 
compatibility, application and implementation need to use these definitions 
(based on the target architecture). ABI is defined by CPU ISA (including 
version, endianism, etc) and SW environment (OS and compiler). Six different 
ABIs are initially defined - all are Linux based and assume the default 
endianism.

Some unused types were found for API spec. Those will be removed once this 
patch set is merged with api-next.

v2:
  * Use strong types as default handle types


Petri Savolainen (8):
  abi: event: added the first ABI spec file
  abi: buffer: added initial definitions
  abi: classifier: added initial definitions
  abi: crypto: added initial definitions
  abi: packet: added initial definitions
  abi: pool: added initial definitions
  abi: queue: added initial definitions
  abi: shm: added initial definitions

 configure.ac   | 22 ++
 example/Makefile.inc   |  1 +
 example/timer/odp_timer_test.c |  2 +-
 helper/Makefile.am |  1 +
 include/odp/arch/arm32-linux/odp/api/abi/buffer.h  |  7 
 .../arch/arm32-linux/odp/api/abi/classification.h  |  7 
 include/odp/arch/arm32-linux/odp/api/abi/crypto.h  |  7 
 include/odp/arch/arm32-linux/odp/api/abi/event.h   |  7 
 include/odp/arch/arm32-linux/odp/api/abi/packet.h  |  7 
 include/odp/arch/arm32-linux/odp/api/abi/pool.h|  7 
 include/odp/arch/arm32-linux/odp/api/abi/queue.h   |  7 
 .../arch/arm32-linux/odp/api/abi/shared_memory.h   |  7 
 include/odp/arch/arm64-linux/odp/api/abi/buffer.h  |  7 
 .../arch/arm64-linux/odp/api/abi/classification.h  |  7 
 include/odp/arch/arm64-linux/odp/api/abi/crypto.h  |  7 
 include/odp/arch/arm64-linux/odp/api/abi/event.h   |  7 
 include/odp/arch/arm64-linux/odp/api/abi/packet.h  |  7 
 include/odp/arch/arm64-linux/odp/api/abi/pool.h|  7 
 include/odp/arch/arm64-linux/odp/api/abi/queue.h   |  7 
 .../arch/arm64-linux/odp/api/abi/shared_memory.h   |  7 
 include/odp/arch/default/api/abi/buffer.h  | 38 +
 include/odp/arch/default/api/abi/classification.h  | 40 ++
 include/odp/arch/default/api/abi/crypto.h  | 36 +
 include/odp/arch/default/api/abi/event.h   | 42 +++
 include/odp/arch/default/api/abi/packet.h  | 47 ++
 include/odp/arch/default/api/abi/pool.h| 43 
 include/odp/arch/default/api/abi/queue.h   | 35 
 include/odp/arch/default/api/abi/shared_memory.h   | 35 
 include/odp/arch/mips64-linux/odp/api/abi/buffer.h |  7 
 .../arch/mips64-linux/odp/api/abi/classification.h |  7 
 include/odp/arch/mips64-linux/odp/api/abi/crypto.h |  7 
 include/odp/arch/mips64-linux/odp/api/abi/event.h  |  7 
 include/odp/arch/mips64-linux/odp/api/abi/packet.h |  7 
 include/odp/arch/mips64-linux/odp/api/abi/pool.h   |  7 
 include/odp/arch/mips64-linux/odp/api/abi/queue.h  |  7 
 .../arch/mips64-linux/odp/api/abi/shared_memory.h  |  7 
 .../odp/arch/power64-linux/odp/api/abi/buffer.h|  7 
 .../power64-linux/odp/api/abi/classification.h |  7 
 .../odp/arch/power64-linux/odp/api/abi/crypto.h|  7 
 include/odp/arch/power64-linux/odp/api/abi/event.h |  7 
 .../odp/arch/power64-linux/odp/api/abi/packet.h|  7 
 include/odp/arch/power64-linux/odp/api/abi/pool.h  |  7 
 include/odp/arch/power64-linux/odp/api/abi/queue.h |  7 
 .../arch/power64-linux/odp/api/abi/shared_memory.h |  7 
 include/odp/arch/x86_32-linux/odp/api/abi/buffer.h |  7 
 .../arch/x86_32-linux/odp/api/abi/classification.h |  7 
 include/odp/arch/x86_32-linux/odp/api/abi/crypto.h |  7 
 include/odp/arch/x86_32-linux/odp/api/abi/event.h  |  7 
 include/odp/arch/x86_32-linux/odp/api/abi/packet.h |  7 
 include/odp/arch/x86_32-linux/odp/api/abi/pool.h   |  7 
 include/odp/arch/x86_32-linux/odp/api/abi/queue.h  |  7 
 .../arch/x86_32-linux/odp/api/abi/shared_memory.h  |  7 
 include/odp/arch/x86_64-linux/odp/api/abi/buffer.h |  7 
 .../arch/x86_64-linux/odp/api/abi/classification.h |  7 
 include/odp/arch/x86_64-linux/odp/api/abi/crypto.h |  7 
 include/odp/arch/x86_64-linux/odp/api/abi/event.h  |  7 
 include/odp/arch/x86_64-linux/odp/api/abi/packet.h |  7 
 include/odp/arch/x86_64-linux/odp/api/abi/pool.h   |  7 
 include/odp/arch/x86_64-linux/odp/api/abi/queue.h  |  7 
 .../arch/x86_64-linux/odp/api/abi/shared_memory.h  |  7 
 platform/Makefile.inc  | 22 ++
 platform/linux-generic/Makefile.am |  1 +
 .../linux-generic/include/odp/api/classification.h |  9

[lng-odp] [PATCH v2 6/8] abi: pool: added initial definitions

2017-01-20 Thread Petri Savolainen

Initially, use the same default ABI file for all architectures.
Default values match those defined in odp-linux implementation
to minimize changes in this phase.

Signed-off-by: Petri Savolainen 
---
 example/timer/odp_timer_test.c |  2 +-
 include/odp/arch/arm32-linux/odp/api/abi/pool.h|  7 
 include/odp/arch/arm64-linux/odp/api/abi/pool.h|  7 
 include/odp/arch/default/api/abi/pool.h| 43 ++
 include/odp/arch/mips64-linux/odp/api/abi/pool.h   |  7 
 include/odp/arch/power64-linux/odp/api/abi/pool.h  |  7 
 include/odp/arch/x86_32-linux/odp/api/abi/pool.h   |  7 
 include/odp/arch/x86_64-linux/odp/api/abi/pool.h   |  7 
 platform/Makefile.inc  |  6 ++-
 .../include/odp/api/plat/pool_types.h  | 21 ++-
 10 files changed, 102 insertions(+), 12 deletions(-)
 create mode 100644 include/odp/arch/arm32-linux/odp/api/abi/pool.h
 create mode 100644 include/odp/arch/arm64-linux/odp/api/abi/pool.h
 create mode 100644 include/odp/arch/default/api/abi/pool.h
 create mode 100644 include/odp/arch/mips64-linux/odp/api/abi/pool.h
 create mode 100644 include/odp/arch/power64-linux/odp/api/abi/pool.h
 create mode 100644 include/odp/arch/x86_32-linux/odp/api/abi/pool.h
 create mode 100644 include/odp/arch/x86_64-linux/odp/api/abi/pool.h

diff --git a/example/timer/odp_timer_test.c b/example/timer/odp_timer_test.c
index 035ab2e..9a393c2 100644
--- a/example/timer/odp_timer_test.c
+++ b/example/timer/odp_timer_test.c
@@ -520,7 +520,7 @@ err:
if (gbls != NULL && gbls->tp != ODP_TIMER_POOL_INVALID)
odp_timer_pool_destroy(gbls->tp);
 
-   if (gbls != NULL && gbls->pool != ODP_TIMER_POOL_INVALID)
+   if (gbls != NULL && gbls->pool != ODP_POOL_INVALID)
if (odp_pool_destroy(gbls->pool))
err = 1;
 
diff --git a/include/odp/arch/arm32-linux/odp/api/abi/pool.h 
b/include/odp/arch/arm32-linux/odp/api/abi/pool.h
new file mode 100644
index 000..b354afb
--- /dev/null
+++ b/include/odp/arch/arm32-linux/odp/api/abi/pool.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/arm64-linux/odp/api/abi/pool.h 
b/include/odp/arch/arm64-linux/odp/api/abi/pool.h
new file mode 100644
index 000..b354afb
--- /dev/null
+++ b/include/odp/arch/arm64-linux/odp/api/abi/pool.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/default/api/abi/pool.h 
b/include/odp/arch/default/api/abi/pool.h
new file mode 100644
index 000..4637d19
--- /dev/null
+++ b/include/odp/arch/default/api/abi/pool.h
@@ -0,0 +1,43 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#ifndef ODP_ABI_POOL_H_
+#define ODP_ABI_POOL_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include 
+
+/** @internal Dummy type for strong typing */
+typedef struct { char dummy; /**< @internal Dummy */ } _odp_abi_pool_t;
+
+/** @ingroup odp_pool
+ *  @{
+ */
+
+typedef _odp_abi_pool_t *odp_pool_t;
+
+#define ODP_POOL_INVALID   ((odp_pool_t)0x)
+
+#define ODP_POOL_NAME_LEN  32
+
+typedef enum odp_pool_type_t {
+   ODP_POOL_BUFFER  = ODP_EVENT_BUFFER,
+   ODP_POOL_PACKET  = ODP_EVENT_PACKET,
+   ODP_POOL_TIMEOUT = ODP_EVENT_TIMEOUT
+} odp_pool_type_t;
+
+/**
+ * @}
+ */
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif
diff --git a/include/odp/arch/mips64-linux/odp/api/abi/pool.h 
b/include/odp/arch/mips64-linux/odp/api/abi/pool.h
new file mode 100644
index 000..b354afb
--- /dev/null
+++ b/include/odp/arch/mips64-linux/odp/api/abi/pool.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/power64-linux/odp/api/abi/pool.h 
b/include/odp/arch/power64-linux/odp/api/abi/pool.h
new file mode 100644
index 000..b354afb
--- /dev/null
+++ b/include/odp/arch/power64-linux/odp/api/abi/pool.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/x86_32-linux/odp/api/abi/pool.h 
b/include/odp/arch/x86_32-linux/odp/api/abi/pool.h
new file mode 100644
index 000..b354afb
--- /dev/null
+++ b/include/odp/arch/x86_32-linux/odp/api/abi/pool.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/x86_64-linux/odp/api/abi/pool.h 
b/include/odp/arch/x86_64-linux/odp/api/abi/pool.h
new file mode 100644
index 000..b354afb
--- /dev/null
+++

[lng-odp] [PATCH v2 4/8] abi: crypto: added initial definitions

2017-01-20 Thread Petri Savolainen

Initially, use the same default ABI file for all architectures.
Default values match those defined in odp-linux implementation
to minimize changes in this phase.

Signed-off-by: Petri Savolainen 
---
 include/odp/arch/arm32-linux/odp/api/abi/crypto.h  |  7 +
 include/odp/arch/arm64-linux/odp/api/abi/crypto.h  |  7 +
 include/odp/arch/default/api/abi/crypto.h  | 36 ++
 include/odp/arch/mips64-linux/odp/api/abi/crypto.h |  7 +
 .../odp/arch/power64-linux/odp/api/abi/crypto.h|  7 +
 include/odp/arch/x86_32-linux/odp/api/abi/crypto.h |  7 +
 include/odp/arch/x86_64-linux/odp/api/abi/crypto.h |  7 +
 platform/Makefile.inc  |  2 ++
 .../include/odp/api/plat/crypto_types.h| 21 +
 platform/linux-generic/odp_crypto.c| 10 ++
 10 files changed, 98 insertions(+), 13 deletions(-)
 create mode 100644 include/odp/arch/arm32-linux/odp/api/abi/crypto.h
 create mode 100644 include/odp/arch/arm64-linux/odp/api/abi/crypto.h
 create mode 100644 include/odp/arch/default/api/abi/crypto.h
 create mode 100644 include/odp/arch/mips64-linux/odp/api/abi/crypto.h
 create mode 100644 include/odp/arch/power64-linux/odp/api/abi/crypto.h
 create mode 100644 include/odp/arch/x86_32-linux/odp/api/abi/crypto.h
 create mode 100644 include/odp/arch/x86_64-linux/odp/api/abi/crypto.h

diff --git a/include/odp/arch/arm32-linux/odp/api/abi/crypto.h 
b/include/odp/arch/arm32-linux/odp/api/abi/crypto.h
new file mode 100644
index 000..9a9d2dc
--- /dev/null
+++ b/include/odp/arch/arm32-linux/odp/api/abi/crypto.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/arm64-linux/odp/api/abi/crypto.h 
b/include/odp/arch/arm64-linux/odp/api/abi/crypto.h
new file mode 100644
index 000..9a9d2dc
--- /dev/null
+++ b/include/odp/arch/arm64-linux/odp/api/abi/crypto.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/default/api/abi/crypto.h 
b/include/odp/arch/default/api/abi/crypto.h
new file mode 100644
index 000..f0793a1
--- /dev/null
+++ b/include/odp/arch/default/api/abi/crypto.h
@@ -0,0 +1,36 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#ifndef ODP_ABI_CRYPTO_H_
+#define ODP_ABI_CRYPTO_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include 
+
+/** @internal Dummy type for strong typing */
+typedef struct { char dummy; /**< @internal Dummy */ } _odp_abi_crypto_compl_t;
+
+/** @ingroup odp_crypto
+ *  @{
+ */
+
+#define ODP_CRYPTO_SESSION_INVALID (0xULL)
+
+typedef uint64_t  odp_crypto_session_t;
+typedef _odp_abi_crypto_compl_t *odp_crypto_compl_t;
+
+/**
+ * @}
+ */
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif
diff --git a/include/odp/arch/mips64-linux/odp/api/abi/crypto.h 
b/include/odp/arch/mips64-linux/odp/api/abi/crypto.h
new file mode 100644
index 000..9a9d2dc
--- /dev/null
+++ b/include/odp/arch/mips64-linux/odp/api/abi/crypto.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/power64-linux/odp/api/abi/crypto.h 
b/include/odp/arch/power64-linux/odp/api/abi/crypto.h
new file mode 100644
index 000..9a9d2dc
--- /dev/null
+++ b/include/odp/arch/power64-linux/odp/api/abi/crypto.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/x86_32-linux/odp/api/abi/crypto.h 
b/include/odp/arch/x86_32-linux/odp/api/abi/crypto.h
new file mode 100644
index 000..9a9d2dc
--- /dev/null
+++ b/include/odp/arch/x86_32-linux/odp/api/abi/crypto.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/x86_64-linux/odp/api/abi/crypto.h 
b/include/odp/arch/x86_64-linux/odp/api/abi/crypto.h
new file mode 100644
index 000..9a9d2dc
--- /dev/null
+++ b/include/odp/arch/x86_64-linux/odp/api/abi/crypto.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/platform/Makefile.inc b/platform/Makefile.inc
index bb40692..29ed347 100644
--- a/platform/Makefile.inc
+++ b/platform/Makefile.inc
@@ -64,12 +64,14 @@ odpapiabidefaultincludedir= 
$(includedir)/odp/arch/default/api/abi
 odpapiabidefaultinclude_HEADERS = \
$(top_srcdir)/include/odp/arch/default/api/abi/buffer.h \
$(top_srcdir)/include/odp/arch/default/api/abi/classification.h \
+

[lng-odp] [PATCH v2 5/8] abi: packet: added initial definitions

2017-01-20 Thread Petri Savolainen

Initially, use the same default ABI file for all architectures.
Default values match those defined in odp-linux implementation
to minimize changes in this phase.

Signed-off-by: Petri Savolainen 
---
 include/odp/arch/arm32-linux/odp/api/abi/packet.h  |  7 
 include/odp/arch/arm64-linux/odp/api/abi/packet.h  |  7 
 include/odp/arch/default/api/abi/packet.h  | 47 ++
 include/odp/arch/mips64-linux/odp/api/abi/packet.h |  7 
 .../odp/arch/power64-linux/odp/api/abi/packet.h|  7 
 include/odp/arch/x86_32-linux/odp/api/abi/packet.h |  7 
 include/odp/arch/x86_64-linux/odp/api/abi/packet.h |  7 
 platform/Makefile.inc  |  6 ++-
 .../include/odp/api/plat/packet_types.h| 26 
 platform/linux-generic/odp_packet.c| 10 +
 10 files changed, 111 insertions(+), 20 deletions(-)
 create mode 100644 include/odp/arch/arm32-linux/odp/api/abi/packet.h
 create mode 100644 include/odp/arch/arm64-linux/odp/api/abi/packet.h
 create mode 100644 include/odp/arch/default/api/abi/packet.h
 create mode 100644 include/odp/arch/mips64-linux/odp/api/abi/packet.h
 create mode 100644 include/odp/arch/power64-linux/odp/api/abi/packet.h
 create mode 100644 include/odp/arch/x86_32-linux/odp/api/abi/packet.h
 create mode 100644 include/odp/arch/x86_64-linux/odp/api/abi/packet.h

diff --git a/include/odp/arch/arm32-linux/odp/api/abi/packet.h 
b/include/odp/arch/arm32-linux/odp/api/abi/packet.h
new file mode 100644
index 000..f44cb53
--- /dev/null
+++ b/include/odp/arch/arm32-linux/odp/api/abi/packet.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/arm64-linux/odp/api/abi/packet.h 
b/include/odp/arch/arm64-linux/odp/api/abi/packet.h
new file mode 100644
index 000..f44cb53
--- /dev/null
+++ b/include/odp/arch/arm64-linux/odp/api/abi/packet.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/default/api/abi/packet.h 
b/include/odp/arch/default/api/abi/packet.h
new file mode 100644
index 000..60a41b8
--- /dev/null
+++ b/include/odp/arch/default/api/abi/packet.h
@@ -0,0 +1,47 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#ifndef ODP_ABI_PACKET_H_
+#define ODP_ABI_PACKET_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include 
+
+/** @internal Dummy type for strong typing */
+typedef struct { char dummy; /**< @internal Dummy */ } _odp_abi_packet_t;
+
+/** @ingroup odp_packet
+ *  @{
+ */
+
+typedef _odp_abi_packet_t *odp_packet_t;
+typedef uint8_todp_packet_seg_t;
+
+#define ODP_PACKET_INVALID((odp_packet_t)0x)
+#define ODP_PACKET_SEG_INVALID((odp_packet_seg_t)-1)
+#define ODP_PACKET_OFFSET_INVALID (0x0fff)
+
+typedef enum {
+   ODP_PACKET_GREEN = 0,
+   ODP_PACKET_YELLOW = 1,
+   ODP_PACKET_RED = 2,
+   ODP_PACKET_ALL_COLORS = 3,
+} odp_packet_color_t;
+
+#define ODP_NUM_PACKET_COLORS 3
+
+/**
+ * @}
+ */
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif
diff --git a/include/odp/arch/mips64-linux/odp/api/abi/packet.h 
b/include/odp/arch/mips64-linux/odp/api/abi/packet.h
new file mode 100644
index 000..f44cb53
--- /dev/null
+++ b/include/odp/arch/mips64-linux/odp/api/abi/packet.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/power64-linux/odp/api/abi/packet.h 
b/include/odp/arch/power64-linux/odp/api/abi/packet.h
new file mode 100644
index 000..f44cb53
--- /dev/null
+++ b/include/odp/arch/power64-linux/odp/api/abi/packet.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/x86_32-linux/odp/api/abi/packet.h 
b/include/odp/arch/x86_32-linux/odp/api/abi/packet.h
new file mode 100644
index 000..f44cb53
--- /dev/null
+++ b/include/odp/arch/x86_32-linux/odp/api/abi/packet.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/x86_64-linux/odp/api/abi/packet.h 
b/include/odp/arch/x86_64-linux/odp/api/abi/packet.h
new file mode 100644
index 000..f44cb53
--- /dev/null
+++ b/include/odp/arch/x86_64-linux/odp/api/abi/packet.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/platform/Makefile.inc b/platform/Makefile.inc
index 29ed347..03d9376 100644
--- a/platform/Makefile.inc
+++ b/platform/Makefile.inc
@@ -65,14

[lng-odp] [PATCH v2 8/8] abi: shm: added initial definitions

2017-01-20 Thread Petri Savolainen

Initially, use the same default ABI file for all architectures.
Default values match those defined in odp-linux implementation
to minimize changes in this phase.

Signed-off-by: Petri Savolainen 
---
 .../arch/arm32-linux/odp/api/abi/shared_memory.h   |  7 +
 .../arch/arm64-linux/odp/api/abi/shared_memory.h   |  7 +
 include/odp/arch/default/api/abi/shared_memory.h   | 35 ++
 .../arch/mips64-linux/odp/api/abi/shared_memory.h  |  7 +
 .../arch/power64-linux/odp/api/abi/shared_memory.h |  7 +
 .../arch/x86_32-linux/odp/api/abi/shared_memory.h  |  7 +
 .../arch/x86_64-linux/odp/api/abi/shared_memory.h  |  7 +
 platform/Makefile.inc  |  6 ++--
 .../include/odp/api/plat/shared_memory_types.h | 16 +-
 platform/linux-generic/include/odp_pool_internal.h |  1 +
 platform/linux-generic/odp_shared_memory.c |  6 
 11 files changed, 96 insertions(+), 10 deletions(-)
 create mode 100644 include/odp/arch/arm32-linux/odp/api/abi/shared_memory.h
 create mode 100644 include/odp/arch/arm64-linux/odp/api/abi/shared_memory.h
 create mode 100644 include/odp/arch/default/api/abi/shared_memory.h
 create mode 100644 include/odp/arch/mips64-linux/odp/api/abi/shared_memory.h
 create mode 100644 include/odp/arch/power64-linux/odp/api/abi/shared_memory.h
 create mode 100644 include/odp/arch/x86_32-linux/odp/api/abi/shared_memory.h
 create mode 100644 include/odp/arch/x86_64-linux/odp/api/abi/shared_memory.h

diff --git a/include/odp/arch/arm32-linux/odp/api/abi/shared_memory.h 
b/include/odp/arch/arm32-linux/odp/api/abi/shared_memory.h
new file mode 100644
index 000..d203678
--- /dev/null
+++ b/include/odp/arch/arm32-linux/odp/api/abi/shared_memory.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/arm64-linux/odp/api/abi/shared_memory.h 
b/include/odp/arch/arm64-linux/odp/api/abi/shared_memory.h
new file mode 100644
index 000..d203678
--- /dev/null
+++ b/include/odp/arch/arm64-linux/odp/api/abi/shared_memory.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/default/api/abi/shared_memory.h 
b/include/odp/arch/default/api/abi/shared_memory.h
new file mode 100644
index 000..5805f95
--- /dev/null
+++ b/include/odp/arch/default/api/abi/shared_memory.h
@@ -0,0 +1,35 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#ifndef ODP_ABI_SHM_H_
+#define ODP_ABI_SHM_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/** @internal Dummy type for strong typing */
+typedef struct { char dummy; /**< @internal Dummy */ } _odp_abi_shm_t;
+
+/** @ingroup odp_shared_memory
+ *  @{
+ */
+
+typedef _odp_abi_shm_t *odp_shm_t;
+
+#define ODP_SHM_INVALID   ((odp_shm_t)0)
+#define ODP_SHM_NULL  ODP_SHM_INVALID
+#define ODP_SHM_NAME_LEN  32
+
+/**
+ * @}
+ */
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif
diff --git a/include/odp/arch/mips64-linux/odp/api/abi/shared_memory.h 
b/include/odp/arch/mips64-linux/odp/api/abi/shared_memory.h
new file mode 100644
index 000..d203678
--- /dev/null
+++ b/include/odp/arch/mips64-linux/odp/api/abi/shared_memory.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/power64-linux/odp/api/abi/shared_memory.h 
b/include/odp/arch/power64-linux/odp/api/abi/shared_memory.h
new file mode 100644
index 000..d203678
--- /dev/null
+++ b/include/odp/arch/power64-linux/odp/api/abi/shared_memory.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/x86_32-linux/odp/api/abi/shared_memory.h 
b/include/odp/arch/x86_32-linux/odp/api/abi/shared_memory.h
new file mode 100644
index 000..d203678
--- /dev/null
+++ b/include/odp/arch/x86_32-linux/odp/api/abi/shared_memory.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/x86_64-linux/odp/api/abi/shared_memory.h 
b/include/odp/arch/x86_64-linux/odp/api/abi/shared_memory.h
new file mode 100644
index 000..d203678
--- /dev/null
+++ b/include/odp/arch/x86_64-linux/odp/api/abi/shared_memory.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/platform/Makefile.inc b/platform/Makefile.inc
index 3201d33..7059d91 100644
--- a/platform/Makefile.inc
+++ b/platform/Makefile.inc
@@ -68,7 +68,8 @@ odpapiabidefaultinclude_HEADERS = \

[lng-odp] [PATCH v2 2/8] abi: buffer: added initial definitions

2017-01-20 Thread Petri Savolainen

Initially, use the same default ABI file for all architectures.
Default values match those defined in odp-linux implementation
to minimize changes in this phase.

Signed-off-by: Petri Savolainen 
---
 include/odp/arch/arm32-linux/odp/api/abi/buffer.h  |  7 
 include/odp/arch/arm64-linux/odp/api/abi/buffer.h  |  7 
 include/odp/arch/default/api/abi/buffer.h  | 38 ++
 include/odp/arch/mips64-linux/odp/api/abi/buffer.h |  7 
 .../odp/arch/power64-linux/odp/api/abi/buffer.h|  7 
 include/odp/arch/x86_32-linux/odp/api/abi/buffer.h |  7 
 include/odp/arch/x86_64-linux/odp/api/abi/buffer.h |  7 
 platform/Makefile.inc  |  2 ++
 .../include/odp/api/plat/buffer_types.h| 23 -
 platform/linux-generic/odp_buffer.c|  5 +++
 10 files changed, 101 insertions(+), 9 deletions(-)
 create mode 100644 include/odp/arch/arm32-linux/odp/api/abi/buffer.h
 create mode 100644 include/odp/arch/arm64-linux/odp/api/abi/buffer.h
 create mode 100644 include/odp/arch/default/api/abi/buffer.h
 create mode 100644 include/odp/arch/mips64-linux/odp/api/abi/buffer.h
 create mode 100644 include/odp/arch/power64-linux/odp/api/abi/buffer.h
 create mode 100644 include/odp/arch/x86_32-linux/odp/api/abi/buffer.h
 create mode 100644 include/odp/arch/x86_64-linux/odp/api/abi/buffer.h

diff --git a/include/odp/arch/arm32-linux/odp/api/abi/buffer.h 
b/include/odp/arch/arm32-linux/odp/api/abi/buffer.h
new file mode 100644
index 000..d9c3193
--- /dev/null
+++ b/include/odp/arch/arm32-linux/odp/api/abi/buffer.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/arm64-linux/odp/api/abi/buffer.h 
b/include/odp/arch/arm64-linux/odp/api/abi/buffer.h
new file mode 100644
index 000..d9c3193
--- /dev/null
+++ b/include/odp/arch/arm64-linux/odp/api/abi/buffer.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/default/api/abi/buffer.h 
b/include/odp/arch/default/api/abi/buffer.h
new file mode 100644
index 000..eec6f01
--- /dev/null
+++ b/include/odp/arch/default/api/abi/buffer.h
@@ -0,0 +1,38 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#ifndef ODP_ABI_BUFFER_H_
+#define ODP_ABI_BUFFER_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/** @internal Dummy type for strong typing */
+typedef struct { char dummy; /**< @internal Dummy */ } _odp_abi_buffer_t;
+
+/** @internal Dummy type for strong typing */
+typedef struct { char dummy; /**< @internal Dummy */ } _odp_abi_buffer_seg_t;
+
+/** @ingroup odp_buffer
+ *  @{
+ */
+
+typedef _odp_abi_buffer_t *odp_buffer_t;
+typedef _odp_abi_buffer_seg_t *odp_buffer_seg_t;
+
+#define ODP_BUFFER_INVALID   ((odp_buffer_t)0x)
+#define ODP_SEGMENT_INVALID  ((odp_buffer_seg_t)0x)
+
+/**
+ * @}
+ */
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif
diff --git a/include/odp/arch/mips64-linux/odp/api/abi/buffer.h 
b/include/odp/arch/mips64-linux/odp/api/abi/buffer.h
new file mode 100644
index 000..d9c3193
--- /dev/null
+++ b/include/odp/arch/mips64-linux/odp/api/abi/buffer.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/power64-linux/odp/api/abi/buffer.h 
b/include/odp/arch/power64-linux/odp/api/abi/buffer.h
new file mode 100644
index 000..d9c3193
--- /dev/null
+++ b/include/odp/arch/power64-linux/odp/api/abi/buffer.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/x86_32-linux/odp/api/abi/buffer.h 
b/include/odp/arch/x86_32-linux/odp/api/abi/buffer.h
new file mode 100644
index 000..d9c3193
--- /dev/null
+++ b/include/odp/arch/x86_32-linux/odp/api/abi/buffer.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/include/odp/arch/x86_64-linux/odp/api/abi/buffer.h 
b/include/odp/arch/x86_64-linux/odp/api/abi/buffer.h
new file mode 100644
index 000..d9c3193
--- /dev/null
+++ b/include/odp/arch/x86_64-linux/odp/api/abi/buffer.h
@@ -0,0 +1,7 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
diff --git a/platform/Makefile.inc b/platform/Makefile.inc
index a24accb..b078df8 100644
--- a/platform/Makefile.inc
+++ b/platform/Makefile.inc
@@ -62,10 +62,12 @@ odpapispecinclude_HEADERS = \
 
 odpapiabidefaultincludedir= $(includedir)/odp/arch/default/api/abi

Re: [lng-odp] [PATCH 0/8] First ABI files

2017-01-20 Thread Savolainen, Petri (Nokia - FI/Espoo)

> > I think we should stop right here of doing "significant changes" through
> api-next. Last time that policy effectively stopped the work in master due
> to dependencies over many files changed. Api-next should be reserved only
> for API spec changing modifications, since only those are visible to
> applications. E.g. changes in ABI does not require any application change.
> Today our "ABI" support is non-existent. This sets ground work for files
> and Makefiles to enable ABI(s) and force that.
> 
> I would argue that we should use branches, the problem was not
> api-next IMHO, but rather we had major changes from multiple
> contributors that collided in that one location. We ended up halting
> all work in api-next whilst the underpinning work was completed, not a
> criticism as such but the same would happen to any single repository
> bottle neck. I think we need to develop on parallel branches and then
> when they are ready they are just merged.
> 
> I could see two important maintainer branches in parallel to master.
> api-next owned by you
> driver owned by  Christophe
> 
> 
> When either of these major work area branches (on your own public
> repo) is ready you just send maxim a pull request and he can be sure
> the branch owners have already attained the required reviews etc.
> 
> Releases are super simple now, all pre tested and reviewed ready to
> go, merge and tag, it also scales to any amount of parallel
> conflicting work.

Mails in plain text, please.

When two developers touch the same lines on the same files, you cannot avoid a 
rebase. Multiple public branches would not make it better but worse, since a 
third/fourth/etc developer would not know which branch is "the latest" / 
official code base (== where to send a bug fix for example). Master should be 
always the branch that most people use and develop on. People that do not want 
to use the latest development, can choose a tagged version of master and stick 
with that (until the next tag).

For example, this ABI work will (eventually) modify all internal xxx_types.h 
files. If / when somebody else will do any modification on those same files, 
there will be a merge conflict.

If we all patch master and merge often, delta (and rebase effort) keeps small. 
Simultaneous, overlapping development on multiple branches (master / api-next / 
driver / xxx)  would just collect a huge rebase or  merge conflict debt that 
nobody wants to solve on the next release point. 

-Petri

Re: [lng-odp] [PATCH 0/8] First ABI files

2017-01-20 Thread Bill Fischofer

On Fri, Jan 20, 2017 at 7:22 AM, Mike Holmes  wrote:
> Note, "driver" would stage though next for CI to look at it just as
> api-next does.
>
> On 20 January 2017 at 08:08, Mike Holmes  wrote:
>> On 20 January 2017 at 04:33, Savolainen, Petri (Nokia - FI/Espoo)
>>  wrote:
 -Original Message-
 From: Bill Fischofer [mailto:bill.fischo...@linaro.org]
 Sent: Thursday, January 19, 2017 11:53 PM
 To: Savolainen, Petri (Nokia - FI/Espoo) 
 Cc: lng-odp-forward 
 Subject: Re: [lng-odp] [PATCH 0/8] First ABI files

 This series represents a significant structural change and as such
 should go against api-next, not master. Patches aimed at master should
 be bug fixes, not something that introduces new structure development.
>>>
>>>
>>> I think we should stop right here of doing "significant changes" through 
>>> api-next. Last time that policy effectively stopped the work in master due 
>>> to dependencies over many files changed. Api-next should be reserved only 
>>> for API spec changing modifications, since only those are visible to 
>>> applications. E.g. changes in ABI does not require any application change. 
>>> Today our "ABI" support is non-existent. This sets ground work for files 
>>> and Makefiles to enable ABI(s) and force that.
>>
>> I would argue that we should use branches, the problem was not
>> api-next IMHO, but rather we had major changes from multiple
>> contributors that collided in that one location. We ended up halting
>> all work in api-next whilst the underpinning work was completed, not a
>> criticism as such but the same would happen to any single repository
>> bottle neck. I think we need to develop on parallel branches and then
>> when they are ready they are just merged.
>>
>> I could see two important maintainer branches in parallel to master.
>> api-next owned by you
>> driver owned by  Christophe
>>
>>
>> When either of these major work area branches (on your own public
>> repo) is ready you just send maxim a pull request and he can be sure
>> the branch owners have already attained the required reviews etc.
>>
>> Releases are super simple now, all pre tested and reviewed ready to
>> go, merge and tag, it also scales to any amount of parallel
>> conflicting work.
>>

+1 for the development branch approach. I think we've reached the
level of maturity in the project where that technique should be the
default for any larger changes.

>>>
>>>

 While the goals here seem good, I'm concerned that at this stage
 applying this removes strong typing support. For example, as an
 experiment I changed the buffer validation test to contain this error:
>>>
>>> I'll look into strong typing as default. But vendors may very well agree 
>>> not to support it, since it requires handles to be pointer size types. E.g. 
>>> arm64 ABI may be agreed to use uint32_t for handles instead of pointers.
>>>
>>> -Petri
>>
>>
>>
>> --
>> Mike Holmes
>> Program Manager - Linaro Networking Group
>> Linaro.org │ Open source software for ARM SoCs
>> "Work should be fun and collaborative, the rest follows"
>
>
>
> --
> Mike Holmes
> Program Manager - Linaro Networking Group
> Linaro.org │ Open source software for ARM SoCs
> "Work should be fun and collaborative, the rest follows"

Re: [lng-odp] 32-bit support in examples

2017-01-20 Thread Francois Ozog

well, yes. But that is the only atomic operation supported. No add, sub,
inc, xadd, bit operations

Le ven. 20 janv. 2017 à 14:31, Joe Savage  a écrit :

> > I wonder what processor supports 128 bits atomics. As far as I know Intel
>
> > does not support it. Lock prefix is not allowed on SSE instructions.
>
>
>
> Actually, Intel does support them through a locked cmpxchg16b. And ARMv8
>
> through load exclusive pair and store exclusive pair.
>
>

Re: [lng-odp] 32-bit support in examples

2017-01-20 Thread Joe Savage

> I wonder what processor supports 128 bits atomics. As far as I know Intel
> does not support it. Lock prefix is not allowed on SSE instructions.

Actually, Intel does support them through a locked cmpxchg16b. And ARMv8
through load exclusive pair and store exclusive pair.

Re: [lng-odp] [PATCH v3 0/4] remove Linux specifics and dependence on test dir

2017-01-20 Thread Mike Holmes

Maxim had two small points, I will fix just those with a v4 and carry
your review forward if that is ok

On 20 January 2017 at 02:05, Christophe Milard
 wrote:
> For the series:
>
> Reviewed-by: Christophe Milard 
>
>
> On 18 January 2017 at 23:01, Mike Holmes  wrote:
>> Starting with some clean up, rename the Linux specific files and then move 
>> them
>> to a platform specific directory. A new configure option is introduced
>> "with-helper-platform", this defaults to match the existing odp selector
>> "with-platform" so that there is no operational change.
>>
>> With the move made the default is to build only the portable helper API, if 
>> the
>> legacy and previously unused Linux thread APIs are needed they can be built 
>> in
>> with --enable-helper-extn
>>
>> Then remove the dependence on the test directory.
>>
>> v2:
>> sort some lists into alphabetical order (Maxim)
>> addtional code simplification removing a .h helper(Christophe)
>>
>> v3:
>> rebase
>> whitespace error is there due to matching existing formatting in file
>>
>> Mike Holmes (4):
>>   configure: use helper configure.m4
>>   helper: cleanup Linux rename to thread
>>   helper: move thread implementation under platform
>>   helper: remove dependence on test dir
>>
>>  configure.ac   |  19 +-
>>  example/Makefile.inc   |   2 +-
>>  example/classifier/odp_classifier.c|   2 +-
>>  example/generator/odp_generator.c  |   2 +-
>>  example/ipsec/odp_ipsec.c  |   2 +-
>>  example/l2fwd_simple/odp_l2fwd_simple.c|   2 +-
>>  example/l3fwd/odp_l3fwd.c  |   2 +-
>>  example/packet/odp_pktio.c |   2 +-
>>  example/switch/odp_switch.c|   2 +-
>>  example/time/time_global_test.c|   5 +-
>>  example/timer/odp_timer_test.c |   2 +-
>>  helper/Makefile.am |  22 +-
>>  .../helper/platform/linux-generic/threads_extn.h   | 112 
>>  helper/include/odp/helper/{linux.h => threads.h}   |  78 -
>>  helper/m4/configure.m4 |  14 +
>>  helper/platform/linux-generic/thread.c | 313 
>> +
>>  helper/test/Makefile.am|  43 ++-
>>  helper/test/chksum.c   |  18 +-
>>  helper/test/cuckootable.c  |   4 +-
>>  helper/test/iplookuptable.c|   4 +-
>>  helper/test/linux-generic/Makefile.am  |   5 +
>>  helper/test/{ => linux-generic}/process.c  |  16 +-
>>  helper/test/{ => linux-generic}/thread.c   |  16 +-
>>  helper/test/odpthreads.c   |  20 +-
>>  helper/test/parse.c|  86 +++---
>>  helper/test/table.c|  12 +-
>>  helper/{linux.c => threads.c}  | 240 +---
>>  ...inux.pc.in => libodphelper-linux-generic.pc.in} |   4 +-
>>  test/Makefile.inc  |   2 +-
>>  test/common_plat/common/odp_cunit_common.c |   2 +-
>>  .../common_plat/miscellaneous/odp_api_from_cpp.cpp |   2 +-
>>  test/common_plat/performance/odp_crypto.c  |   2 +-
>>  test/common_plat/performance/odp_l2fwd.c   |   2 +-
>>  test/common_plat/performance/odp_pktio_perf.c  |   2 +-
>>  test/common_plat/performance/odp_sched_latency.c   |   2 +-
>>  test/common_plat/performance/odp_scheduling.c  |   2 +-
>>  test/common_plat/validation/api/Makefile.inc   |   2 +-
>>  test/common_plat/validation/api/timer/timer.c  |   2 +-
>>  test/linux-generic/Makefile.inc|   2 +-
>>  test/linux-generic/mmap_vlan_ins/mmap_vlan_ins.c   |   2 +-
>>  test/linux-generic/pktio_ipc/ipc_common.h  |   2 +-
>>  test/linux-generic/ring/ring_stress.c  |   2 +-
>>  42 files changed, 633 insertions(+), 444 deletions(-)
>>  create mode 100644 
>> helper/include/odp/helper/platform/linux-generic/threads_extn.h
>>  rename helper/include/odp/helper/{linux.h => threads.h} (74%)
>>  create mode 100644 helper/platform/linux-generic/thread.c
>>  create mode 100644 helper/test/linux-generic/Makefile.am
>>  rename helper/test/{ => linux-generic}/process.c (84%)
>>  rename helper/test/{ => linux-generic}/thread.c (84%)
>>  rename helper/{linux.c => threads.c} (67%)
>>  rename pkgconfig/{libodphelper-linux.pc.in => 
>> libodphelper-linux-generic.pc.in} (72%)
>>
>> --
>> 2.9.3



-- 
Mike Holmes
Program Manager - Linaro Networking Group
Linaro.org │ Open source software for ARM SoCs
"Work should be fun and collaborative, the rest follows"

Re: [lng-odp] [PATCH 0/8] First ABI files

2017-01-20 Thread Mike Holmes

Note, "driver" would stage though next for CI to look at it just as
api-next does.

On 20 January 2017 at 08:08, Mike Holmes  wrote:
> On 20 January 2017 at 04:33, Savolainen, Petri (Nokia - FI/Espoo)
>  wrote:
>>> -Original Message-
>>> From: Bill Fischofer [mailto:bill.fischo...@linaro.org]
>>> Sent: Thursday, January 19, 2017 11:53 PM
>>> To: Savolainen, Petri (Nokia - FI/Espoo) >> labs.com>
>>> Cc: lng-odp-forward 
>>> Subject: Re: [lng-odp] [PATCH 0/8] First ABI files
>>>
>>> This series represents a significant structural change and as such
>>> should go against api-next, not master. Patches aimed at master should
>>> be bug fixes, not something that introduces new structure development.
>>
>>
>> I think we should stop right here of doing "significant changes" through 
>> api-next. Last time that policy effectively stopped the work in master due 
>> to dependencies over many files changed. Api-next should be reserved only 
>> for API spec changing modifications, since only those are visible to 
>> applications. E.g. changes in ABI does not require any application change. 
>> Today our "ABI" support is non-existent. This sets ground work for files and 
>> Makefiles to enable ABI(s) and force that.
>
> I would argue that we should use branches, the problem was not
> api-next IMHO, but rather we had major changes from multiple
> contributors that collided in that one location. We ended up halting
> all work in api-next whilst the underpinning work was completed, not a
> criticism as such but the same would happen to any single repository
> bottle neck. I think we need to develop on parallel branches and then
> when they are ready they are just merged.
>
> I could see two important maintainer branches in parallel to master.
> api-next owned by you
> driver owned by  Christophe
>
>
> When either of these major work area branches (on your own public
> repo) is ready you just send maxim a pull request and he can be sure
> the branch owners have already attained the required reviews etc.
>
> Releases are super simple now, all pre tested and reviewed ready to
> go, merge and tag, it also scales to any amount of parallel
> conflicting work.
>
>>
>>
>>>
>>> While the goals here seem good, I'm concerned that at this stage
>>> applying this removes strong typing support. For example, as an
>>> experiment I changed the buffer validation test to contain this error:
>>
>> I'll look into strong typing as default. But vendors may very well agree not 
>> to support it, since it requires handles to be pointer size types. E.g. 
>> arm64 ABI may be agreed to use uint32_t for handles instead of pointers.
>>
>> -Petri
>
>
>
> --
> Mike Holmes
> Program Manager - Linaro Networking Group
> Linaro.org │ Open source software for ARM SoCs
> "Work should be fun and collaborative, the rest follows"



-- 
Mike Holmes
Program Manager - Linaro Networking Group
Linaro.org │ Open source software for ARM SoCs
"Work should be fun and collaborative, the rest follows"

Re: [lng-odp] 32-bit support in examples

2017-01-20 Thread Francois Ozog

I wonder what processor supports 128 bits atomics. As far as I know Intel
does not support it. Lock prefix is not allowed on SSE instructions.

FF

Le ven. 20 janv. 2017 à 13:59, Joe Savage  a écrit :

> > Unfortunately, ODP atomics API does not support 128 bit atomics - at
> least
>
> > currently. So, your example could not use those anyway. Not all 64 CPUs
>
> > have 128 bit atomic instructions.
>
>
>
> Yes, this is unfortunate. For the time being I am using GCC's __atomic
>
> operations such as __atomic_compare_exchange, which can use lock-based
>
> implementations if necessary. I did look at using the ODP atomics API for
> the
>
> 64-bit case, but doing so would require even more structural changes and
>
> exceptions for the 32-bit case to the point of madness. Assuming 128-bit
>
> atomics get introduced in future, it probably makes sense to port the full
>
> example over to using the official API at that point.
>
>

Re: [lng-odp] memory allocation issues

2017-01-20 Thread Maxim Uvarov

On 01/19/17 19:18, Steve Capper wrote:
> On 19 January 2017 at 13:04, Christophe Milard
>  wrote:
>> Hi Steve,
> 
> Hey Christophe,
> 
>>
>> Maybe you remember me as we have had contact before. Christophe. from
>> the LNG ODP team (mikes Holmes team).
>>
>> I have written the ODP memory allocator and I am having an issue with
>> it: It has a requirement that linux processes (we call them ODP
>> threads) have to be able to share memory between each other, as normal
>> pthreads do. (an "ODP thread" can be either a linux process or a
>> pthread)
>> The memory should be shareable (at same virtual address) even if it is
>> ODP allocated after processes have fork()'d.
>>
>> I did that the following way: as all our ODP processes are descendant
>> of a single root process (we call it the ODP instantiation process), I
>> actually pre-reserve a large virtual space area in this process). this
>> is done as follows:
>>
>>  pre_reserved_zone = mmap(NULL, len, PROT_NONE,  MAP_SHARED |
>> MAP_ANONYMOUS | MAP_NORESERVE, -1, 0);
>>
>> The PROT_NONE makes sure that the physical memory is unaccessible,
>> hence not used.
>>
>> Later, when one of the linux processes does an odp_reserve(), in the
>> related mmap(), I want to map the real memory on some part of that
>> preallocated area, using MAP_FIXED:
>>
>> mapped_addr = mmap(start, size, PROT_READ | PROT_WRITE, MAP_SHARED |
>> MAP_FIXED | mmap_flags, fd, 0);
>>
>> If "start" is in the pre_reserved_zone, we know it is available in all
>> processes, as the prereserved zone is inheritaed by all (because they
>> are all descendent of the instantiation process which did this
>> pre-reservation)
>>
>> However, I noticed that, for huge pages at least, if this call fails
>> due to a lack of huge pages, the virtual space (from start to
>> start+size), seems to be returned as available to the kernel! I
>> expected a failed call to leave the system unchanged, not to do half
>> of the job...
> 
> Unfortunately this appears to make sense due to the pluggable logic in
> the kernel. If one mmaps a location, anything in the way is first
> munmapp'ed. We need to call munmap as the previous mmap may have been
> from special driver logic (remember one can supply an mmap handler for
> a driver). Likewise due to the munmap also being potentially special,
> we can't roll this back. The only safe thing we can do is leave the
> space empty if the later mmap logic fails.
> (Also it took me a while and a very strong coffee to understand this,
> so it certainly isn't obvious :-)).
> 
> 
>> This is of course a problem, since I want my pre-reserved area to
>> remain pre-reserved on failure!
>> What I did (until now), is that I simply remade the pre-reservation
>> (with PROT_NONE) on the specific area behind the failed call.
>> This was OK, I though, as concurrent access (from different thread) to
>> my odp_reserve() function are mutexed.
>> What I forgot is that the differrent threads can actually use malloc()
>> or mmap() directely:
>> If a thread 1 does a odp_reserve, fails on lack of huge page (point A
>> in the code) and re-pre-reserve the area (point B), another thread 2
>> could be unlucky enough to do a mmap(NULL,...) between thread 1's A
>> and B, and be returned a part of my so-called preallocated address
>> space :-(.
>>
>> So I am working on another strategy: doing a first mapping outside the
>> preallocated space, and, on success only, move the resulting area
>> (using mremap) into the proeallocated space.
>>
>> The patch (from the old strategy to the new one) looks as flllows:
>> -   mapped_addr = mmap(start, size, PROT_READ | PROT_WRITE,
>> -  MAP_SHARED | MAP_FIXED | mmap_flags, fd, 
>> 0);
>> -   /* if mapping fails, re-block the space we tried to take
>> -* as it seems a mapping failure still affect what was 
>> there??*/
>> -   if (mapped_addr == MAP_FAILED) {
>> -   mmap_flags = MAP_SHARED | MAP_FIXED |
>> -MAP_ANONYMOUS | MAP_NORESERVE;
>> -   mmap(start, size, PROT_NONE, mmap_flags, -1, 0);
>> -   mprotect(start, size, PROT_NONE);
>> +   /* first, try a normal map. If that works, we move it
>> +* where it should be:
>> +* This is because it turned out that if a mapping fails
>> +* on a the prereserved virtual address space, then
>> +* the prereserved address space which was tried to be mapped
>> +* on becomes available to the kernel again! This was not
>> +* according to expectations: the assumption was that if a
>> +* mapping fails, the system should remain unchanged, but 
>> this
>> +* is obvioulsy not true (at least for huge pages when
>> +* exhausted).
>> +* So the strategy is to first map at a non

Re: [lng-odp] [PATCH 0/8] First ABI files

2017-01-20 Thread Mike Holmes

On 20 January 2017 at 04:33, Savolainen, Petri (Nokia - FI/Espoo)
 wrote:
>> -Original Message-
>> From: Bill Fischofer [mailto:bill.fischo...@linaro.org]
>> Sent: Thursday, January 19, 2017 11:53 PM
>> To: Savolainen, Petri (Nokia - FI/Espoo) > labs.com>
>> Cc: lng-odp-forward 
>> Subject: Re: [lng-odp] [PATCH 0/8] First ABI files
>>
>> This series represents a significant structural change and as such
>> should go against api-next, not master. Patches aimed at master should
>> be bug fixes, not something that introduces new structure development.
>
>
> I think we should stop right here of doing "significant changes" through 
> api-next. Last time that policy effectively stopped the work in master due to 
> dependencies over many files changed. Api-next should be reserved only for 
> API spec changing modifications, since only those are visible to 
> applications. E.g. changes in ABI does not require any application change. 
> Today our "ABI" support is non-existent. This sets ground work for files and 
> Makefiles to enable ABI(s) and force that.

I would argue that we should use branches, the problem was not
api-next IMHO, but rather we had major changes from multiple
contributors that collided in that one location. We ended up halting
all work in api-next whilst the underpinning work was completed, not a
criticism as such but the same would happen to any single repository
bottle neck. I think we need to develop on parallel branches and then
when they are ready they are just merged.

I could see two important maintainer branches in parallel to master.
api-next owned by you
driver owned by  Christophe

When either of these major work area branches (on your own public
repo) is ready you just send maxim a pull request and he can be sure
the branch owners have already attained the required reviews etc.

Releases are super simple now, all pre tested and reviewed ready to
go, merge and tag, it also scales to any amount of parallel
conflicting work.

>
>
>>
>> While the goals here seem good, I'm concerned that at this stage
>> applying this removes strong typing support. For example, as an
>> experiment I changed the buffer validation test to contain this error:
>
> I'll look into strong typing as default. But vendors may very well agree not 
> to support it, since it requires handles to be pointer size types. E.g. arm64 
> ABI may be agreed to use uint32_t for handles instead of pointers.
>
> -Petri

-- 
Mike Holmes
Program Manager - Linaro Networking Group
Linaro.org │ Open source software for ARM SoCs
"Work should be fun and collaborative, the rest follows"

Re: [lng-odp] 32-bit support in examples

2017-01-20 Thread Joe Savage

> Unfortunately, ODP atomics API does not support 128 bit atomics - at least
> currently. So, your example could not use those anyway. Not all 64 CPUs
> have 128 bit atomic instructions.

Yes, this is unfortunate. For the time being I am using GCC's __atomic
operations such as __atomic_compare_exchange, which can use lock-based
implementations if necessary. I did look at using the ODP atomics API for the
64-bit case, but doing so would require even more structural changes and
exceptions for the 32-bit case to the point of madness. Assuming 128-bit
atomics get introduced in future, it probably makes sense to port the full
example over to using the official API at that point.

Re: [lng-odp] 32-bit support in examples

2017-01-20 Thread Savolainen, Petri (Nokia - FI/Espoo)



> -Original Message-
> From: Joe Savage [mailto:joe.sav...@arm.com]
> Sent: Friday, January 20, 2017 1:51 PM
> To: Savolainen, Petri (Nokia - FI/Espoo)  labs.com>; Maxim Uvarov ; lng-
> o...@lists.linaro.org; Bill Fischofer 
> Cc: nd 
> Subject: Re: [lng-odp] 32-bit support in examples
> 
> > Agree with Maxim. I which way the application is not 32 bit compliant?
> 
> It uses 128-bit atomics, and so is really designed for execution on 64-bit
> machines. It is possible to provide lockless 32-bit support in this case,
> though, and I have an implementation that does so. Since the pointer size
> is
> halved and there is a pointer in the 128-bit struct, I just have to squash
> a
> few of the other fields down (managing them carefully) so that 64-bit
> atomics
> can be used instead.

Unfortunately, ODP atomics API does not support 128 bit atomics - at least 
currently. So, your example could not use those anyway. Not all 64 CPUs have 
128 bit atomic instructions.

> 
> On reflection, I think that providing 32-bit support is probably
> worthwhile
> here, so I will do so. It does add a little complexity to the code, but
> it's
> not actually that much, and there are clear benefits from having the
> example
> be better supported on different platforms.
> 
> I do think that having a place for 64-bit only examples in the future
> (e.g.
> an "example_64" directory as Bill outlined) might be useful though. It
> isn't
> always so easy to add 32-bit support.

Good. ODP provides 32 and 64 bit atomics (also on 32 bit CPUs), so you can 
still utilize those. In addition, synchronization / critical sections should 
touch only a small portion of the application code base and preferably in a 
modular way (inside enqueue() / dequeue(), push() / pop(), etc functions).

-Petri

Re: [lng-odp] 32-bit support in examples

2017-01-20 Thread Joe Savage

> Agree with Maxim. I which way the application is not 32 bit compliant?

It uses 128-bit atomics, and so is really designed for execution on 64-bit
machines. It is possible to provide lockless 32-bit support in this case,
though, and I have an implementation that does so. Since the pointer size is
halved and there is a pointer in the 128-bit struct, I just have to squash a
few of the other fields down (managing them carefully) so that 64-bit atomics
can be used instead.

On reflection, I think that providing 32-bit support is probably worthwhile
here, so I will do so. It does add a little complexity to the code, but it's
not actually that much, and there are clear benefits from having the example
be better supported on different platforms.

I do think that having a place for 64-bit only examples in the future (e.g.
an "example_64" directory as Bill outlined) might be useful though. It isn't
always so easy to add 32-bit support.

Re: [lng-odp] 32-bit support in examples

2017-01-20 Thread Savolainen, Petri (Nokia - FI/Espoo)



> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Maxim
> Uvarov
> Sent: Thursday, January 19, 2017 3:27 PM
> To: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] 32-bit support in examples
> 
> On 01/19/17 16:23, Joe Savage wrote:
> > Hey,
> >
> > I'm just finalising a patch to add a lock-free IPv4 fragmentation and
> > reassembly example to ODP, and it has occurred to me that as the whole
> > examples directory is compiled with odp-linux by default, I ought to be
> > careful about supporting a wide variety of platforms (ensuring that my
> change
> > doesn't break any builds).
> >
> > I was initially planning to submit the example with 64-bit support only.
> This
> > simplifies the implementation, and should cater for most of the
> important
> > cases, but could cause issues on 32-bit platforms. How valuable does the
> > community view 32-bit support in an example? If it's worthwhile, I can
> add
> > the support at the cost of complexity, but if not, perhaps I can apply
> some
> > form of conditional compilation such that my example only builds on
> > supported platforms.
> >
> > Joe
> >
> 
> 
> It's better to support both. At least for now we support both everywhere
> and CI also triggers build for 32.
> 
> Maxim.

Agree with Maxim. I which way the application is not 32 bit compliant?

-Petri

Re: [lng-odp] [PATCH v2 1/2] linux-gen: align: round up power of two as macro

2017-01-20 Thread Yi He

For this patch series, I've reviewed and tested good against master branch:

Reviewed-and-tested-by: Yi He 

On api-next branch it encounters compilation error, what's our typical
solution for this kind of problem?
_ishmpool.c:209:3: error: implicit declaration of function ‘
ODP_CACHE_LINE_SIZE_ROUNDUP’

Best Regards, Yi

On 20 January 2017 at 17:14, Petri Savolainen 
wrote:

> Implement round up to power of two as a macro. Macro
> enables preprocessor to calculate the constant value and
> avoid code generation. Also dependency to __builtin_clz()
> is not needed anymore.
>
> Signed-off-by: Petri Savolainen 
> ---
>  .../linux-generic/include/odp_align_internal.h | 26
> +++---
>  platform/linux-generic/odp_pool.c  |  2 +-
>  platform/linux-generic/odp_schedule_sp.c   |  2 +-
>  3 files changed, 20 insertions(+), 10 deletions(-)
>
> diff --git a/platform/linux-generic/include/odp_align_internal.h
> b/platform/linux-generic/include/odp_align_internal.h
> index d9cd30b..e5b2f37 100644
> --- a/platform/linux-generic/include/odp_align_internal.h
> +++ b/platform/linux-generic/include/odp_align_internal.h
> @@ -18,6 +18,7 @@ extern "C" {
>  #endif
>
>  #include 
> +#include 
>
>  /** @addtogroup odp_compiler_optim
>   *  @{
> @@ -27,6 +28,23 @@ extern "C" {
>   * Round up
>   */
>
> +/* Macros to calculate ODP_ROUNDUP_POWER2_U32() in five rounds of shift
> + * and OR operations. */
> +#define _RSHIFT_U32(x, y) (((uint32_t)(x)) >> (y))
> +#define _POW2_U32_R1(x)   (((uint32_t)(x)) | _RSHIFT_U32(x, 1))
> +#define _POW2_U32_R2(x)   (_POW2_U32_R1(x) | _RSHIFT_U32(_POW2_U32_R1(x),
> 2))
> +#define _POW2_U32_R3(x)   (_POW2_U32_R2(x) | _RSHIFT_U32(_POW2_U32_R2(x),
> 4))
> +#define _POW2_U32_R4(x)   (_POW2_U32_R3(x) | _RSHIFT_U32(_POW2_U32_R3(x),
> 8))
> +#define _POW2_U32_R5(x)   (_POW2_U32_R4(x) | _RSHIFT_U32(_POW2_U32_R4(x),
> 16))
> +
> +/* Round up a uint32_t value 'x' to the next power of two.
> + *
> + * The value is not round up, if it's already a power of two (including
> 1).
> + * The value must be larger than 0 and not exceed 0x8000.
> + */
> +#define ODP_ROUNDUP_POWER2_U32(x) \
> +   uint32_t)(x)) > 0x8000) ? 0 : (_POW2_U32_R5(x - 1) + 1))
> +
>  /**
>   * @internal
>   * Round up 'x' to alignment 'align'
> @@ -36,14 +54,6 @@ extern "C" {
>
>  /**
>   * @internal
> - * When 'x' is not already a power of two, round it up to the next
> - * power of two value. Zero is not supported as an input value.
> - */
> -#define ODP_ROUNDUP_POWER_2(x)\
> -   (1 << (((int)(8 * sizeof(x))) - __builtin_clz((x) - 1)))
> -
> -/**
> - * @internal
>   * Round up pointer 'x' to alignment 'align'
>   */
>  #define ODP_ALIGN_ROUNDUP_PTR(x, align)\
> diff --git a/platform/linux-generic/odp_pool.c
> b/platform/linux-generic/odp_pool.c
> index 090a55f..0d12d0b 100644
> --- a/platform/linux-generic/odp_pool.c
> +++ b/platform/linux-generic/odp_pool.c
> @@ -381,7 +381,7 @@ static odp_pool_t pool_create(const char *name,
> odp_pool_param_t *params,
> if (num <= RING_SIZE_MIN)
> ring_size = RING_SIZE_MIN;
> else
> -   ring_size = ODP_ROUNDUP_POWER_2(num);
> +   ring_size = ODP_ROUNDUP_POWER2_U32(num);
>
> pool->ring_mask  = ring_size - 1;
> pool->num= num;
> diff --git a/platform/linux-generic/odp_schedule_sp.c
> b/platform/linux-generic/odp_schedule_sp.c
> index 5150d28..5ccd32d 100644
> --- a/platform/linux-generic/odp_schedule_sp.c
> +++ b/platform/linux-generic/odp_schedule_sp.c
> @@ -34,7 +34,7 @@
>  #define GROUP_PKTIN   GROUP_ALL
>
>  /* Maximum number of commands: one priority/group for all queues and
> pktios */
> -#define RING_SIZE (ODP_ROUNDUP_POWER_2(NUM_QUEUE + NUM_PKTIO))
> +#define RING_SIZE (ODP_ROUNDUP_POWER2_U32(NUM_QUEUE + NUM_PKTIO))
>  #define RING_MASK (RING_SIZE - 1)
>
>  /* Ring size must be power of two */
> --
> 2.8.1
>
>

Re: [lng-odp] Scheduling packets from control threads

2017-01-20 Thread Radosław Biernacki

Hi,

I would propose to add more clear description about posibility of calling
the ODP API for event and packet processing.
For e.g it is unclear now if CONTROL threads can operate on queues or
scheduler.

 51  * Control threads do not participate the main packet flow
through the
 52  * system, but e.g. control or monitor the worker threads, or
handle
 53  * exceptions. These threads may perform general purpose
processing,
 54  * use system calls, share the CPU with other threads and be
interrupt
 55  * driven.
+ Those threads can use all ODP API functions including pktio, queues and
scheduler.

2017-01-20 9:26 GMT+01:00 Stanislaw Kardach :

> On 01/19/2017 06:06 PM, Bill Fischofer wrote:
>
>> On Thu, Jan 19, 2017 at 10:03 AM, Stanislaw Kardach 
>> wrote:
>>
>>>
>>>
>>> Best Regards,
>>> Stanislaw Kardach
>>>
>>>
>>> On 01/19/2017 04:57 PM, Bill Fischofer wrote:
>>>

 On Thu, Jan 19, 2017 at 7:17 AM, Stanislaw Kardach 
 wrote:

>
> Hi all,
>
> While going through thread and scheduler APIs I've stumbled on one
> uncertainty in ODP API that I could not find straight solution to.
>
> Does ODP allow scheduling packets from an ODP_THREAD_CONTROL thread?
>

 When a thread calls odp_schedule() the only requirement is that it be
 a member of a schedule group that contains queues of type
 ODP_QUEUE_TYPE_SCHED.  Since threads by default are in group
 ODP_SCHED_GROUP_ALL and that's also the default scheduler group for
 queues, this is normally not a consideration.

> If yes then what would be the difference between ODP_THREAD_CONTROL and
> ODP_THREAD_WORKER threads beside isolating cores for worker threads?
> API
> suggests this approach as both control and worker threads are treated
> the
> same way in odp_thrmask_* calls. Moreover:
> a. schedule groups take odp_thrmask_t (no comment on whether it has
>to only contain worker threads)
> b. There is a schedule group ODP_SCHED_GROUP_ALL which would imply that
>user can create a scheduler queue that control threads can use.
>

 The provision of WORKER/CONTROL threads is for application convenience
 in organizing itself. But there is no semantic difference between the
 two as far as the ODP API spec is concerned.

> On the other hand I can find the following in ODP_THREAD_CONTROL
> description: "Control threads do not participate the main packet flow
> through the system". That looks to me like an implication that control
> threads should not do any packet processing. However if that's the case
> then
> ODP_THREAD_COUNT_MAX does not differentiate between worker or control
> threads and similarly  odp_thrmask_t doesn't (and by extension schedule
> groups).
>

 The expectation here is that worker threads will want to run on
 isolated cores for best performance while control thread can share
 cores and be timesliced without performance impact. That's the main
 reason for having this division. Threads that do performance-critical
 work would normally be designated worker thread while those that do
 less performance-critical work would be designated as control threads.
 Again, this is a convenience feature that applications can use to
 manage core/thread assignments but ODP imposes no requirements on
 applications in this area.

> To put this discussion in a concrete context, on the platform which I'm
> working on, each thread that wants to interact with a scheduler needs
> to
> do
> it via special hardware handle of which I have a limited number. For me
> it
> makes sense to reserve such handles only for threads which are going to
> do
> the traffic processing (hence worker threads) and leave control threads
> unlimited. In summary let application spawn as many control threads as
> it
> wants but limit worker threads by the amount of handles that I have to
> spare.
>

 That's certainly one possibility. On such platforms the odp_schedule()
 API might take the thread type into consideration in determining how
 to process schedule requests, however in the case you outline a better
 and more portable way might be to have a hardware-queue schedule group
 and assign queues that are holding performance-critical events to that
 schedule group. The point is that both applications and ODP
 implementations have a lot of flexibility in how they operate within
 the ODP API spec.

 Do I understand you correctly that this hardware-queue schedule group
>>> would
>>> be the one to utilize the "hardware handles" (and hence hardware
>>> scheduler)
>>> where as other schedule groups rely on software scheduler?
>>>
>>
>> That would be one

Re: [lng-odp] [PATCH 0/8] First ABI files

2017-01-20 Thread Savolainen, Petri (Nokia - FI/Espoo)

> -Original Message-
> From: Bill Fischofer [mailto:bill.fischo...@linaro.org]
> Sent: Thursday, January 19, 2017 11:53 PM
> To: Savolainen, Petri (Nokia - FI/Espoo)  labs.com>
> Cc: lng-odp-forward 
> Subject: Re: [lng-odp] [PATCH 0/8] First ABI files
> 
> This series represents a significant structural change and as such
> should go against api-next, not master. Patches aimed at master should
> be bug fixes, not something that introduces new structure development.


I think we should stop right here of doing "significant changes" through 
api-next. Last time that policy effectively stopped the work in master due to 
dependencies over many files changed. Api-next should be reserved only for API 
spec changing modifications, since only those are visible to applications. E.g. 
changes in ABI does not require any application change. Today our "ABI" support 
is non-existent. This sets ground work for files and Makefiles to enable ABI(s) 
and force that. 


> 
> While the goals here seem good, I'm concerned that at this stage
> applying this removes strong typing support. For example, as an
> experiment I changed the buffer validation test to contain this error:

I'll look into strong typing as default. But vendors may very well agree not to 
support it, since it requires handles to be pointer size types. E.g. arm64 ABI 
may be agreed to use uint32_t for handles instead of pointers.

-Petri

Re: [lng-odp] [PATCH] linux-gen: align: round up power of two as macro

2017-01-20 Thread Savolainen, Petri (Nokia - FI/Espoo)


> +#define ODP_ROUNDUP_POWER2_U32(x) \
> +       (((x) > 0x8000) ? 0 : (_POW2_U32_R5(x - 1) + 1))
> 
> it's better to not name internal macros with ODP_
> 
> 
> Agree, but that's the current convention over the odp_align_interal.h. All
> are internal macros and are ODP_ prefixed. Another patch could rename all
> of those and maybe clean up all other internal files also.
> 

I did rename everything on v2 / patch 2.

-Petri

Re: [lng-odp] [PATCH] linux-gen: align: round up power of two as macro

2017-01-20 Thread Savolainen, Petri (Nokia - FI/Espoo)


> >  /**
> >   * @internal
> > - * When 'x' is not already a power of two, round it up to the next
> > - * power of two value. Zero is not supported as an input value.
> > - */
> > -#define ODP_ROUNDUP_POWER_2(x)\
> > -   (1 << (((int)(8 * sizeof(x))) - __builtin_clz((x) - 1)))
> > + * Round up a uint32_t value 'x' to the next power of two. It's not
> round up,
> > + * if it's already a power of two. It must be larger than 0 and must
> not exceed
> 
> Macro fails and reports ODP_ROUNDUP_POWER_2(1) == 1 instead of the
> correct answer 2. Probably easier to just document that arg must be >
> 1 unless you want to special-case this endpoint.


Sent v2 which addresses this. Actually, 1 is also a power of two (2^0).


> 
> > + * 0x8000.
> > + */
> > +#define _SHIFT_U32(x, y)  (((uint32_t)(x)) >> (y))
> > +#define _POW2_U32_R1(x)   (((uint32_t)(x)) | _SHIFT_U32(x, 1))
> > +#define _POW2_U32_R2(x)   (_POW2_U32_R1(x) |
> _SHIFT_U32(_POW2_U32_R1(x), 2))
> > +#define _POW2_U32_R3(x)   (_POW2_U32_R2(x) |
> _SHIFT_U32(_POW2_U32_R2(x), 4))
> > +#define _POW2_U32_R4(x)   (_POW2_U32_R3(x) |
> _SHIFT_U32(_POW2_U32_R3(x), 8))
> > +#define _POW2_U32_R5(x)   (_POW2_U32_R4(x) |
> _SHIFT_U32(_POW2_U32_R4(x), 16))
> > +
> > +#define ODP_ROUNDUP_POWER2_U32(x) \
> > +   (((x) > 0x8000) ? 0 : (_POW2_U32_R5(x - 1) + 1))
> 
> Should be (((uint32_t)(x)) ... ) here otherwise fails if arg is not
> unsigned.

This is also in v2.

-Petri

[lng-odp] [PATCH v2 2/2] linux-gen: align: clean up macros

2017-01-20 Thread Petri Savolainen

Removed unused  macros from odp_align_internal.h. Renamed remaining
macros without ODP_ prefix and with shorter names.

Signed-off-by: Petri Savolainen 
---
 .../linux-generic/include/odp_align_internal.h | 88 ++
 .../include/odp_classification_datamodel.h |  4 +-
 platform/linux-generic/include/odp_packet_dpdk.h   |  2 +-
 .../linux-generic/include/odp_packet_io_internal.h |  2 +-
 platform/linux-generic/include/odp_packet_netmap.h |  2 +-
 .../linux-generic/include/odp_queue_internal.h |  2 +-
 platform/linux-generic/odp_packet.c|  4 +-
 platform/linux-generic/odp_pool.c  | 12 +--
 platform/linux-generic/odp_schedule.c  |  8 +-
 platform/linux-generic/odp_schedule_sp.c   |  7 +-
 platform/linux-generic/odp_timer.c |  9 +--
 11 files changed, 32 insertions(+), 108 deletions(-)

diff --git a/platform/linux-generic/include/odp_align_internal.h 
b/platform/linux-generic/include/odp_align_internal.h
index e5b2f37..61ff200 100644
--- a/platform/linux-generic/include/odp_align_internal.h
+++ b/platform/linux-generic/include/odp_align_internal.h
@@ -20,14 +20,6 @@ extern "C" {
 #include 
 #include 
 
-/** @addtogroup odp_compiler_optim
- *  @{
- */
-
-/*
- * Round up
- */
-
 /* Macros to calculate ODP_ROUNDUP_POWER2_U32() in five rounds of shift
  * and OR operations. */
 #define _RSHIFT_U32(x, y) (((uint32_t)(x)) >> (y))
@@ -42,95 +34,31 @@ extern "C" {
  * The value is not round up, if it's already a power of two (including 1).
  * The value must be larger than 0 and not exceed 0x8000.
  */
-#define ODP_ROUNDUP_POWER2_U32(x) \
+#define ROUNDUP_POWER2_U32(x) \
uint32_t)(x)) > 0x8000) ? 0 : (_POW2_U32_R5(x - 1) + 1))
 
-/**
- * @internal
+/*
  * Round up 'x' to alignment 'align'
  */
-#define ODP_ALIGN_ROUNDUP(x, align)\
+#define ROUNDUP_ALIGN(x, align)\
((align) * (((x) + (align) - 1) / (align)))
 
-/**
- * @internal
- * Round up pointer 'x' to alignment 'align'
- */
-#define ODP_ALIGN_ROUNDUP_PTR(x, align)\
-   ((void *)ODP_ALIGN_ROUNDUP((uintptr_t)(x), (uintptr_t)(align)))
-
-/**
- * @internal
+/*
  * Round up 'x' to cache line size alignment
  */
-#define ODP_CACHE_LINE_SIZE_ROUNDUP(x)\
-   ODP_ALIGN_ROUNDUP(x, ODP_CACHE_LINE_SIZE)
-
-/**
- * @internal
- * Round up pointer 'x' to cache line size alignment
- */
-#define ODP_CACHE_LINE_SIZE_ROUNDUP_PTR(x)\
-   ((void *)ODP_CACHE_LINE_SIZE_ROUNDUP((uintptr_t)(x)))
-
-/**
- * @internal
- * Round up 'x' to page size alignment
- */
-#define ODP_PAGE_SIZE_ROUNDUP(x)\
-   ODP_ALIGN_ROUNDUP(x, ODP_PAGE_SIZE)
+#define ROUNDUP_CACHE_LINE(x)\
+   ROUNDUP_ALIGN(x, ODP_CACHE_LINE_SIZE)
 
 /*
- * Round down
- */
-
-/**
- * @internal
  * Round down 'x' to 'align' alignment, which is a power of two
  */
-#define ODP_ALIGN_ROUNDDOWN_POWER_2(x, align)\
+#define ROUNDDOWN_POWER2(x, align)\
((x) & (~((align) - 1)))
-/**
- * @internal
- * Round down 'x' to cache line size alignment
- */
-#define ODP_CACHE_LINE_SIZE_ROUNDDOWN(x)\
-   ODP_ALIGN_ROUNDDOWN_POWER_2(x, ODP_CACHE_LINE_SIZE)
-
-/**
- * @internal
- * Round down pointer 'x' to 'align' alignment, which is a power of two
- */
-#define ODP_ALIGN_ROUNDDOWN_PTR_POWER_2(x, align)\
-((void *)ODP_ALIGN_ROUNDDOWN_POWER_2((uintptr_t)(x), (uintptr_t)(align)))
-
-/**
- * @internal
- * Round down pointer 'x' to cache line size alignment
- */
-#define ODP_CACHE_LINE_SIZE_ROUNDDOWN_PTR(x)\
-   ((void *)ODP_CACHE_LINE_SIZE_ROUNDDOWN((uintptr_t)(x)))
 
 /*
- * Check align
- */
-
-/**
- * @internal
- * Check if pointer 'x' is aligned to 'align', which is a power of two
- */
-#define ODP_ALIGNED_CHECK_POWER_2(x, align)\
-   uintptr_t)(x)) & (((uintptr_t)(align))-1)) == 0)
-
-/**
- * @internal
  * Check if value is a power of two
  */
-#define ODP_VAL_IS_POWER_2(x) x)-1) & (x)) == 0)
-
-/**
- * @}
- */
+#define CHECK_IS_POWER2(x) x) - 1) & (x)) == 0)
 
 #ifdef __cplusplus
 }
diff --git a/platform/linux-generic/include/odp_classification_datamodel.h 
b/platform/linux-generic/include/odp_classification_datamodel.h
index 8505c67..f6393ee 100644
--- a/platform/linux-generic/include/odp_classification_datamodel.h
+++ b/platform/linux-generic/include/odp_classification_datamodel.h
@@ -92,7 +92,7 @@ struct cos_s {
 
 typedef union cos_u {
struct cos_s s;
-   uint8_t pad[ODP_CACHE_LINE_SIZE_ROUNDUP(sizeof(struct cos_s))];
+   uint8_t pad[ROUNDUP_CACHE_LINE(sizeof(struct cos_s))];
 } cos_t;
 
 
@@ -112,7 +112,7 @@ struct pmr_s {
 
 typedef union pmr_u {
struct pmr_s s;
-   uint8_t pad[ODP_CACHE_LINE_SIZE_ROUNDUP(sizeof(struct pmr_s))];
+   uint8_t pad[ROUNDUP_CACHE_LINE(sizeof(struct pmr_s))];
 } pmr_t;
 
 /**
diff --git a/platform/linux-generic/include/odp_packet_dpdk.h 
b/platform/linux-generic/include/odp_packet_dpdk.h
index c63685e..4d7e0fc 100644
--- a/platform/linux-generic/include/odp_packet_dpdk.h
+++

[lng-odp] [PATCH v2 1/2] linux-gen: align: round up power of two as macro

2017-01-20 Thread Petri Savolainen

Implement round up to power of two as a macro. Macro
enables preprocessor to calculate the constant value and
avoid code generation. Also dependency to __builtin_clz()
is not needed anymore.

Signed-off-by: Petri Savolainen 
---
 .../linux-generic/include/odp_align_internal.h | 26 +++---
 platform/linux-generic/odp_pool.c  |  2 +-
 platform/linux-generic/odp_schedule_sp.c   |  2 +-
 3 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/platform/linux-generic/include/odp_align_internal.h 
b/platform/linux-generic/include/odp_align_internal.h
index d9cd30b..e5b2f37 100644
--- a/platform/linux-generic/include/odp_align_internal.h
+++ b/platform/linux-generic/include/odp_align_internal.h
@@ -18,6 +18,7 @@ extern "C" {
 #endif
 
 #include 
+#include 
 
 /** @addtogroup odp_compiler_optim
  *  @{
@@ -27,6 +28,23 @@ extern "C" {
  * Round up
  */
 
+/* Macros to calculate ODP_ROUNDUP_POWER2_U32() in five rounds of shift
+ * and OR operations. */
+#define _RSHIFT_U32(x, y) (((uint32_t)(x)) >> (y))
+#define _POW2_U32_R1(x)   (((uint32_t)(x)) | _RSHIFT_U32(x, 1))
+#define _POW2_U32_R2(x)   (_POW2_U32_R1(x) | _RSHIFT_U32(_POW2_U32_R1(x), 2))
+#define _POW2_U32_R3(x)   (_POW2_U32_R2(x) | _RSHIFT_U32(_POW2_U32_R2(x), 4))
+#define _POW2_U32_R4(x)   (_POW2_U32_R3(x) | _RSHIFT_U32(_POW2_U32_R3(x), 8))
+#define _POW2_U32_R5(x)   (_POW2_U32_R4(x) | _RSHIFT_U32(_POW2_U32_R4(x), 16))
+
+/* Round up a uint32_t value 'x' to the next power of two.
+ *
+ * The value is not round up, if it's already a power of two (including 1).
+ * The value must be larger than 0 and not exceed 0x8000.
+ */
+#define ODP_ROUNDUP_POWER2_U32(x) \
+   uint32_t)(x)) > 0x8000) ? 0 : (_POW2_U32_R5(x - 1) + 1))
+
 /**
  * @internal
  * Round up 'x' to alignment 'align'
@@ -36,14 +54,6 @@ extern "C" {
 
 /**
  * @internal
- * When 'x' is not already a power of two, round it up to the next
- * power of two value. Zero is not supported as an input value.
- */
-#define ODP_ROUNDUP_POWER_2(x)\
-   (1 << (((int)(8 * sizeof(x))) - __builtin_clz((x) - 1)))
-
-/**
- * @internal
  * Round up pointer 'x' to alignment 'align'
  */
 #define ODP_ALIGN_ROUNDUP_PTR(x, align)\
diff --git a/platform/linux-generic/odp_pool.c 
b/platform/linux-generic/odp_pool.c
index 090a55f..0d12d0b 100644
--- a/platform/linux-generic/odp_pool.c
+++ b/platform/linux-generic/odp_pool.c
@@ -381,7 +381,7 @@ static odp_pool_t pool_create(const char *name, 
odp_pool_param_t *params,
if (num <= RING_SIZE_MIN)
ring_size = RING_SIZE_MIN;
else
-   ring_size = ODP_ROUNDUP_POWER_2(num);
+   ring_size = ODP_ROUNDUP_POWER2_U32(num);
 
pool->ring_mask  = ring_size - 1;
pool->num= num;
diff --git a/platform/linux-generic/odp_schedule_sp.c 
b/platform/linux-generic/odp_schedule_sp.c
index 5150d28..5ccd32d 100644
--- a/platform/linux-generic/odp_schedule_sp.c
+++ b/platform/linux-generic/odp_schedule_sp.c
@@ -34,7 +34,7 @@
 #define GROUP_PKTIN   GROUP_ALL
 
 /* Maximum number of commands: one priority/group for all queues and pktios */
-#define RING_SIZE (ODP_ROUNDUP_POWER_2(NUM_QUEUE + NUM_PKTIO))
+#define RING_SIZE (ODP_ROUNDUP_POWER2_U32(NUM_QUEUE + NUM_PKTIO))
 #define RING_MASK (RING_SIZE - 1)
 
 /* Ring size must be power of two */
-- 
2.8.1

Re: [lng-odp] Scheduling packets from control threads

2017-01-20 Thread Stanislaw Kardach


On 01/19/2017 06:06 PM, Bill Fischofer wrote:

On Thu, Jan 19, 2017 at 10:03 AM, Stanislaw Kardach  wrote:



Best Regards,
Stanislaw Kardach


On 01/19/2017 04:57 PM, Bill Fischofer wrote:


On Thu, Jan 19, 2017 at 7:17 AM, Stanislaw Kardach 
wrote:


Hi all,

While going through thread and scheduler APIs I've stumbled on one
uncertainty in ODP API that I could not find straight solution to.

Does ODP allow scheduling packets from an ODP_THREAD_CONTROL thread?



When a thread calls odp_schedule() the only requirement is that it be
a member of a schedule group that contains queues of type
ODP_QUEUE_TYPE_SCHED.  Since threads by default are in group
ODP_SCHED_GROUP_ALL and that's also the default scheduler group for
queues, this is normally not a consideration.



If yes then what would be the difference between ODP_THREAD_CONTROL and
ODP_THREAD_WORKER threads beside isolating cores for worker threads? API
suggests this approach as both control and worker threads are treated the
same way in odp_thrmask_* calls. Moreover:
a. schedule groups take odp_thrmask_t (no comment on whether it has
   to only contain worker threads)
b. There is a schedule group ODP_SCHED_GROUP_ALL which would imply that
   user can create a scheduler queue that control threads can use.



The provision of WORKER/CONTROL threads is for application convenience
in organizing itself. But there is no semantic difference between the
two as far as the ODP API spec is concerned.



On the other hand I can find the following in ODP_THREAD_CONTROL
description: "Control threads do not participate the main packet flow
through the system". That looks to me like an implication that control
threads should not do any packet processing. However if that's the case
then
ODP_THREAD_COUNT_MAX does not differentiate between worker or control
threads and similarly  odp_thrmask_t doesn't (and by extension schedule
groups).



The expectation here is that worker threads will want to run on
isolated cores for best performance while control thread can share
cores and be timesliced without performance impact. That's the main
reason for having this division. Threads that do performance-critical
work would normally be designated worker thread while those that do
less performance-critical work would be designated as control threads.
Again, this is a convenience feature that applications can use to
manage core/thread assignments but ODP imposes no requirements on
applications in this area.



To put this discussion in a concrete context, on the platform which I'm
working on, each thread that wants to interact with a scheduler needs to
do
it via special hardware handle of which I have a limited number. For me
it
makes sense to reserve such handles only for threads which are going to
do
the traffic processing (hence worker threads) and leave control threads
unlimited. In summary let application spawn as many control threads as it
wants but limit worker threads by the amount of handles that I have to
spare.



That's certainly one possibility. On such platforms the odp_schedule()
API might take the thread type into consideration in determining how
to process schedule requests, however in the case you outline a better
and more portable way might be to have a hardware-queue schedule group
and assign queues that are holding performance-critical events to that
schedule group. The point is that both applications and ODP
implementations have a lot of flexibility in how they operate within
the ODP API spec.


Do I understand you correctly that this hardware-queue schedule group would
be the one to utilize the "hardware handles" (and hence hardware scheduler)
where as other schedule groups rely on software scheduler?


That would be one possible way to organize an ODP implementation. You
could have a scheduling group that takes full advantage of HW
scheduling capabilities while others rely on SW scheduling. Or you
could share limited HW scheduling objects and use them as a sort of
cache to accelerate all queues, relying on the fact that those more
frequently used would tend to be those threads/queues doing heavy
packet processing. It's really up to the implementer as to how they
want to organize things.

Correct me if I'm wrong but having both HW and SW scheduler with the 
current API would require to move packets between SW and HW schedulers 
which in general can be pain to maintain ordering at acceptable speeds?


The second approach can be problematic for some platforms when the HW 
scheduling objects also hold ordering context which would make it a very 
complex task to make sure the order is maintained when another thread is 
trying to use the scheduling object.


What I'm trying to point out is that it seems a bit confusing to let the 
ODP implementation know of the type of a thread and act on it and yet do 
not allow it specifying any capabilities in that sense, i.e. number of 
worker and control threads separately and if any of

[lng-odp] [PATCH] linux-gen: _ishm: fix normal page fallback

2017-01-20 Thread Christophe Milard

Fixing failure due to lack of huge pages.

Signed-off-by: Christophe Milard 
---
 platform/linux-generic/_ishm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/platform/linux-generic/_ishm.c b/platform/linux-generic/_ishm.c
index f889834..3797f20 100644
--- a/platform/linux-generic/_ishm.c
+++ b/platform/linux-generic/_ishm.c
@@ -547,7 +547,7 @@ static void *do_map(int block_index, uint64_t len, uint32_t 
align,
addr = alloc_fragment(len, block_index, align, );
if (!addr) {
ODP_ERR("alloc_fragment failed.\n");
-   if (new_block->filename[0]) {
+   if (!new_block->external_fd) {
close(*fd);
*fd = -1;
delete_file(new_block);
@@ -562,7 +562,7 @@ static void *do_map(int block_index, uint64_t len, uint32_t 
align,
if (mapped_addr == NULL) {
if (flags & _ODP_ISHM_SINGLE_VA)
free_fragment(fragment);
-   if (new_block->filename[0]) {
+   if (!new_block->external_fd) {
close(*fd);
*fd = -1;
delete_file(new_block);
-- 
2.7.4

45 matches

Mail list logo