[lng-odp] [PATCH v1 0/1] test: linux-generic: stop dropping other ODP files in pktio_ips test
Prevent pktio_ipc test from removing sockets and SHM files used by other applications. github /** Email created from pull request 41 (lumag:patch-1) ** https://github.com/Linaro/odp/pull/41 ** Patch: https://github.com/Linaro/odp/pull/41.patch ** Base sha: ea134fe159c0d249e4bed12b7269e8236afa0262 ** Merge commit sha: 47b7463fed4e1b33ab3e25985bbd489776193f2a **/ /github checkpatch.pl total: 0 errors, 0 warnings, 0 checks, 9 lines checked to_send-p-000.patch has no obvious style problems and is ready for submission. /checkpatch.pl
[lng-odp] [PATCH v1 1/1] test: linux-generic: stop dropping other ODP files in pktio_ips test
From: Dmitry Eremin-Solenikov
Prevent pktio_ipc test from removing sockets and SHM files used by other
applications.
Signed-off-by: Dmitry Eremin-Solenikov
---
/** Email created from pull request 41 (lumag:patch-1)
** https://github.com/Linaro/odp/pull/41
** Patch: https://github.com/Linaro/odp/pull/41.patch
** Base sha: ea134fe159c0d249e4bed12b7269e8236afa0262
** Merge commit sha: 47b7463fed4e1b33ab3e25985bbd489776193f2a
**/
test/linux-generic/pktio_ipc/pktio_ipc_run.sh | 3 ---
1 file changed, 3 deletions(-)
diff --git a/test/linux-generic/pktio_ipc/pktio_ipc_run.sh
b/test/linux-generic/pktio_ipc/pktio_ipc_run.sh
index 52e8d42a..331ecdc9 100755
--- a/test/linux-generic/pktio_ipc/pktio_ipc_run.sh
+++ b/test/linux-generic/pktio_ipc/pktio_ipc_run.sh
@@ -20,9 +20,6 @@ PATH=.:$PATH
run()
{
local ret=0
- #if test was interrupted with CTRL+c than files
- #might remain in shm. Needed cleanely delete them.
- rm -rf /tmp/odp-* 2>&1 > /dev/null
echo " run pktio_ipc1 then pktio_ipc2 "
pktio_ipc1${EXEEXT} -t 10 &
[lng-odp] [PATCH v1 1/1] travis: split build into separate stages
From: Dmitry Eremin-Solenikov
Introduce separate parallel builds for checkpatch, doxygen, distcheck
and plain checks.
Signed-off-by: Dmitry Eremin-Solenikov
---
/** Email created from pull request 40 (lumag:stages)
** https://github.com/Linaro/odp/pull/40
** Patch: https://github.com/Linaro/odp/pull/40.patch
** Base sha: ea134fe159c0d249e4bed12b7269e8236afa0262
** Merge commit sha: 7b96c1fd8a5988d046b34742e9ba0683a9f9070e
**/
.travis.yml | 133 +---
1 file changed, 65 insertions(+), 68 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 65edfbb3..7e4735d9 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -33,65 +33,50 @@ env:
# you need generated new one at https://codecov.io specific for your repo.
- CODECOV_TOKEN=8e1c0fd8-62ff-411e-a79f-5839f6662c11
-matrix:
- include:
-- compiler: gcc
- addons:
-apt:
- sources:
-- ubuntu-toolchain-r-test
- packages:
-- gcc
- env: MY_CF="-O0 -coverage" MY_LDF="--coverage" DOCOV=1
-- compiler: clang
- addons:
-apt:
- sources:
-- ubuntu-toolchain-r-test
-- llvm-toolchain-precise-3.8
- packages:
-- clang-3.8
-- compiler: gcc
- addons:
+addons:
apt:
- sources:
-- ubuntu-toolchain-r-test
- packages:
-- gcc
- env: TEST="CHECKPATCH"
+sources:
+- ubuntu-toolchain-r-test
+- llvm-toolchain-precise-3.8
+packages:
+- gcc
+- clang-3.8
+- automake autoconf libtool libssl-dev graphviz mscgen
doxygen
+- libpcap-dev
+#coverity_scan:
+#project:
+#name: "$TRAVIS_REPO_SLUG"
+#notification_email:
+#build_command_prepend: "./bootstrap && ./configure
--enable-test-cpp --enable-test-vald --enable-test-helper --enable-test-perf
--enable-user-guides --enable-test-perf-proc --enable-test-example"
+#build_command: "make"
+#branch_pattern: coverity_scan
+
+compiler:
+- gcc
+- clang-3.8
-before_install:
+install:
- echo 1000 | sudo tee /proc/sys/vm/nr_hugepages
- sudo mkdir -p /mnt/huge
- sudo mount -t hugetlbfs nodev /mnt/huge
-- if [ "$TEST" = "CHECKPATCH" ]; then
-echo ${TRAVIS_COMMIT_RANGE};
-ODP_PATCHES=`echo ${TRAVIS_COMMIT_RANGE} | sed 's/\.//'`;
-if [ -z "${ODP_PATCHES}" ]; then env; exit 1; fi;
-./scripts/ci-checkpatches.sh ${ODP_PATCHES};
-exit $?;
- fi
-
- sudo apt-get -qq update
-- sudo apt-get install automake autoconf libtool libssl-dev graphviz
mscgen doxygen
-- sudo apt-get install libpcap-dev linux-headers-`uname -r`
+- sudo apt-get install linux-headers-`uname -r`
- sudo pip install coverage
- gem install asciidoctor
- PATH=${PATH//:\.\/node_modules\/\.bin/}
-- if [ "$CC" = "clang" ]; then export CXX="clang++-3.8" CC="clang-3.8"
LD="clang-3.8"; fi
# Install cunit for the validation tests because distro version is too
old and fails C99 compile
- sudo apt-get remove libcunit1-dev libcunit1
- export CUNIT_VERSION=2.1-3
- curl -sSOL
https://github.com/Linaro/libcunit/releases/download/${CUNIT_VERSION}/CUnit-${CUNIT_VERSION}.tar.bz2
- tar -jxf *.bz2
-- cd CUnit*
+- pushd CUnit*
- ./bootstrap
- ./configure --enable-debug --enable-automated --enable-basic
--enable-console --enable-examples --enable-test
- make
- sudo make install
-- cd ..
+- popd
- export LD_LIBRARY_PATH="/usr/local/lib:$LD_LIBRARY_PATH"
# DPDK pktio
@@ -103,30 +88,21 @@ before_install:
- pushd ${TARGET}
- sed -ri 's,(CONFIG_RTE_LIBRTE_PMD_PCAP=).*,\1y,' .config
- popd
-- make install T=${TARGET} EXTRA_CFLAGS="-fPIC" > /dev/null
+- make install T=${TARGET} EXTRA_CFLAGS="-fPIC"
- popd
# Netmap pktio
-- sudo apt-get source linux-image-$(uname -r) > /dev/null
-- KSRC="$PWD/`find . -name kernel-parameters.txt | cut -d / -f 2 `"
- git -c advice.detachedHead=false clone -q --depth=1 --single-branch
--branch=v11.2 https://github.com/luigirizzo/netmap.git
- pushd netmap/LINUX
-- ./configure --kernel-sources=$KSRC
-- make > /dev/null
+- ./configure
+- make
- sudo insmod ./netmap.ko
- popd
script:
- ./bootstrap
-- ./configure
-#doxygen does not trap on warnings, check for them here.
-- make doxygen-doc |tee doxygen.log
-- fgr
[lng-odp] [PATCH v1 0/1] travis: split build into separate stages
Introduce separate parallel builds for checkpatch, doxygen, distcheck and plain checks. Signed-off-by: Dmitry Eremin-Solenikov dmitry.ereminsoleni...@linaro.org github /** Email created from pull request 40 (lumag:stages) ** https://github.com/Linaro/odp/pull/40 ** Patch: https://github.com/Linaro/odp/pull/40.patch ** Base sha: ea134fe159c0d249e4bed12b7269e8236afa0262 ** Merge commit sha: 7b96c1fd8a5988d046b34742e9ba0683a9f9070e **/ /github checkpatch.pl total: 0 errors, 0 warnings, 0 checks, 180 lines checked to_send-p-000.patch has no obvious style problems and is ready for submission. /checkpatch.pl
[lng-odp] [PATCH API-NEXT v1 1/1] travis: add linking with libconfig
From: Maxim Uvarov
libconfig is needed for api-next branch to compile the app.
Signed-off-by: Maxim Uvarov
---
/** Email created from pull request 39 (muvarov:api-next)
** https://github.com/Linaro/odp/pull/39
** Patch: https://github.com/Linaro/odp/pull/39.patch
** Base sha: f20dee9db3da9425d8764e414b04cdcbd41bece8
** Merge commit sha: 7a0255d59bdfd533a8726f9e6c6499caf1f41af0
**/
.travis.yml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 8228f1d2..ab91b9b4 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -133,10 +133,10 @@ script:
- echo "Checking linking and run from install..."
- pushd $HOME
- echo "Dynamic link.."
-- ${CC} ${OLDPWD}/example/hello/odp_hello.c -o odp_hello_inst
-I${HOME}/odp-install/include -L${HOME}/odp-install/lib -lodp-linux
-L${OLDPWD}/dpdk/x86_64-native-linuxapp-gcc/lib -lrt -ldpdk -lpthread -lcrypto
-lpcap $MY_CF $MY_LDF -ldl
+- ${CC} ${OLDPWD}/example/hello/odp_hello.c -o odp_hello_inst
-I${HOME}/odp-install/include -L${HOME}/odp-install/lib -lodp-linux
-L${OLDPWD}/dpdk/x86_64-native-linuxapp-gcc/lib -lrt -ldpdk -lpthread -lcrypto
-lpcap -lconfig $MY_CF $MY_LDF -ldl
- LD_LIBRARY_PATH="${HOME}/odp-install/lib:$LD_LIBRARY_PATH"
./odp_hello_inst
- echo "Static link.."
-- ${CC} ${OLDPWD}/example/hello/odp_hello.c -o odp_hello_inst
-I${HOME}/odp-install/include -L${HOME}/odp-install/lib -lodp-linux
-L${OLDPWD}/dpdk/x86_64-native-linuxapp-gcc/lib -lrt -ldpdk -lpthread -lcrypto
-lpcap $MY_CF $MY_LDF -ldl -static
+- ${CC} ${OLDPWD}/example/hello/odp_hello.c -o odp_hello_inst
-I${HOME}/odp-install/include -L${HOME}/odp-install/lib -lodp-linux
-L${OLDPWD}/dpdk/x86_64-native-linuxapp-gcc/lib -lrt -ldpdk -lpthread -lcrypto
-lpcap -lconfig $MY_CF $MY_LDF -ldl -static
- ./odp_hello_inst
- popd
[lng-odp] [PATCH API-NEXT v1 0/1] travis: add linking with libconfig
libconfig is needed for api-next branch to compile the app. Signed-off-by: Maxim Uvarov maxim.uva...@linaro.org -- Dmitry works to make pktconfig work but that is quick fix for api next to fix linking. After master merge it's needed to add -lconfig to make app compile in api-next branch. This patch is quick and restores travis work back. github /** Email created from pull request 39 (muvarov:api-next) ** https://github.com/Linaro/odp/pull/39 ** Patch: https://github.com/Linaro/odp/pull/39.patch ** Base sha: f20dee9db3da9425d8764e414b04cdcbd41bece8 ** Merge commit sha: 7a0255d59bdfd533a8726f9e6c6499caf1f41af0 **/ /github checkpatch.pl total: 0 errors, 0 warnings, 0 checks, 12 lines checked to_send-p-000.patch has no obvious style problems and is ready for submission. /checkpatch.pl
Re: [lng-odp] [PATCH 0/3] Fix pktio with single segment packet pool
Good bug catch. I've opened Bug https://bugs.linaro.org/show_bug.cgi?id=3013 to track this and assigned it to Matias and noted that he's posted a patch to address this. Maxim: Can we please reference this Bug in the merge commit? For this series: Reviewed-and-tested-by: Bill Fischofer On Wed, May 24, 2017 at 9:40 AM, Maxim Uvarov wrote: > if it is useful case let's add this test to .travis.yaml > > Maxim. > > On 24 May 2017 at 17:35, Matias Elo wrote: > >> This patch set enables using packet pool in single segment mode >> (CONFIG_PACKET_MAX_SEGS = 1). >> >> Matias Elo (3): >> linux-gen: packet: fix odp_packet_free_multi() with single segment >> pool >> linux-gen: packet: fix gcc errors with single segment pool >> test: pktio: use capability to set test pool packet length >> >> platform/linux-generic/odp_packet.c | 16 +++- >> test/common_plat/validation/api/pktio/pktio.c | 7 +-- >> 2 files changed, 16 insertions(+), 7 deletions(-) >> >> -- >> 2.7.4 >> >>
[lng-odp] [Bug 3013] Various failures if CONFIG_PACKET_MAX_SEGS is set to 1
https://bugs.linaro.org/show_bug.cgi?id=3013 Bill Fischofer changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |IN_PROGRESS --- Comment #1 from Bill Fischofer --- Matias has posted patch series http://patches.opendataplane.org/project/lng-odp/list/?series=196 to address this bug. -- You are receiving this mail because: You are on the CC list for the bug.
[lng-odp] [Bug 3013] New: Various failures if CONFIG_PACKET_MAX_SEGS is set to 1
https://bugs.linaro.org/show_bug.cgi?id=3013 Bug ID: 3013 Summary: Various failures if CONFIG_PACKET_MAX_SEGS is set to 1 Product: OpenDataPlane - linux- generic reference Version: v1.14.0.0 Hardware: Other OS: Linux Status: UNCONFIRMED Severity: enhancement Priority: --- Component: Buffers & Packets Assignee: matias@nokia.com Reporter: bill.fischo...@linaro.org CC: lng-odp@lists.linaro.org Target Milestone: --- Reported by Matias. If CONFIG_PACKET_MAX_SEGS is set to 1 ODP gets compile failures and the odp_packet_free_multi() code addresses out of bounds. -- You are receiving this mail because: You are on the CC list for the bug.
[lng-odp] [Linaro/odp] 4d6197: api: crypto: add sha-1 and sha-512 enumerations
Branch: refs/heads/next Home: https://github.com/Linaro/odp Commit: 4d619768d75e4e1c15bb1be7fe282dff532f166b https://github.com/Linaro/odp/commit/4d619768d75e4e1c15bb1be7fe282dff532f166b Author: Petri Savolainen Date: 2017-05-24 (Wed, 24 May 2017) Changed paths: M include/odp/api/spec/crypto.h Log Message: --- api: crypto: add sha-1 and sha-512 enumerations Added enumerations for HMAC-SHA-1 and HMAC-SHA-256 authentication algorithms. Signed-off-by: Petri Savolainen Reviewed-by: Dmitry Eremin-Solenikov Signed-off-by: Maxim Uvarov Commit: cd14a67e875c4edb809c5e9c4f1f3e9a018b3c91 https://github.com/Linaro/odp/commit/cd14a67e875c4edb809c5e9c4f1f3e9a018b3c91 Author: Petri Savolainen Date: 2017-05-24 (Wed, 24 May 2017) Changed paths: M include/odp/api/spec/crypto.h M platform/linux-generic/odp_crypto.c Log Message: --- api: crypto: enforce deprecated API status Used ODP_DEPRECATE() to control if deprecated API definitions are visible in the API or not. Signed-off-by: Petri Savolainen Reviewed-by: Dmitry Eremin-Solenikov Reviewed-by: Bill Fischofer Signed-off-by: Maxim Uvarov Commit: af4a068fa640f50dd72ebcb5ac02ca1510d4119e https://github.com/Linaro/odp/commit/af4a068fa640f50dd72ebcb5ac02ca1510d4119e Author: Petri Savolainen Date: 2017-05-24 (Wed, 24 May 2017) Changed paths: M include/odp/api/spec/crypto.h Log Message: --- api: crypto: add digest length session parameter Authentication capabilities list supported digest lengths per algorithm, but application did not have means to select which length is used. Signed-off-by: Petri Savolainen Reviewed-by: Dmitry Eremin-Solenikov Signed-off-by: Maxim Uvarov Commit: ffce96cbcdef44fe089746e9fc06f982ecdb1932 https://github.com/Linaro/odp/commit/ffce96cbcdef44fe089746e9fc06f982ecdb1932 Author: Petri Savolainen Date: 2017-05-24 (Wed, 24 May 2017) Changed paths: M include/odp/api/spec/crypto.h Log Message: --- api: crypto: add AAD operation parameters Authentication capabilities list supported AAD lengths per algorithm, but application did not have means to select which length is used. Also pointer to AAD is added, since it may be constructed also outside of packet data. Signed-off-by: Petri Savolainen Reviewed-by: Dmitry Eremin-Solenikov Signed-off-by: Maxim Uvarov Commit: 253681892e97ee0f4f7a5c1c1a27b4b336833bcb https://github.com/Linaro/odp/commit/253681892e97ee0f4f7a5c1c1a27b4b336833bcb Author: Dmitry Eremin-Solenikov Date: 2017-05-24 (Wed, 24 May 2017) Changed paths: M include/odp/api/spec/crypto.h M include/odp/api/spec/packet.h M test/common_plat/validation/api/crypto/odp_crypto_test_inp.c M test/common_plat/validation/api/crypto/test_vectors.h Log Message: --- api: packet: introduce odp_packet_data_range_t Rename odp_crypto_data_range_t to odp_packet_data_range_t, as it is relevant not only to the crypto interface. Signed-off-by: Dmitry Eremin-Solenikov Reviewed-by: Petri Savolainen Signed-off-by: Maxim Uvarov Commit: d39b01ce075fa73386096d5960762741fb2805f6 https://github.com/Linaro/odp/commit/d39b01ce075fa73386096d5960762741fb2805f6 Author: Petri Savolainen Date: 2017-05-24 (Wed, 24 May 2017) Changed paths: M configure.ac M doc/application-api-guide/api_guide_lines.dox M doc/platform-api-guide/Doxyfile M doc/process-guide/release-guide.adoc M include/odp/api/spec/.gitignore A include/odp/api/spec/deprecated.h.in M include/odp_api.h M platform/Makefile.inc M platform/linux-generic/Makefile.am A platform/linux-generic/include/odp/api/deprecated.h Log Message: --- api: deprecated: add configure option and macros Added configuration option --enable-deprecated to control if deprecated APIs are enabled or disabled. Added ODP_DEPRECATED_API macro into the API. Its value can be used to check if deprecated API definitions are enabled or disabled. Deprecated APIs are disabled by default. Deprecated APIs are meant to be removed completely in a later API version. Added ODP_DEPRECATE() macro to enforce deprecation of API definitions. When deprecated APIs are disabled, the macro renames API definitions so that application cannot use those any more, but a single implementation library can serve applications built with both options. Signed-off-by: Petri Savolainen Reviewed-by: Dmitry Eremin-Solenikov Reviewed-by: Bill Fischofer Signed-off-by: Maxim Uvarov Commit: c1201795da7e0b21e63c496ff632af02b10dc7d1 https://github.com/Linaro/odp/commit/c1201795da7e0b21e63c496ff632af02b10dc7d1 Author: Petri Savolainen Date: 2017-05-24 (Wed, 24 May 2017) Changed paths: M example/ipsec/odp_ipsec_misc.h M example/ipsec/odp_ipsec_sa_db.c M example/ipsec/odp_ipsec_stream.c M test/common_plat/performance/odp_crypto.c Log Message: ---
[lng-odp] [Linaro/odp] c951ba: api: classification: add additional doxygen docume...
Branch: refs/heads/next Home: https://github.com/Linaro/odp Commit: c951ba0386581a87675477456e3df0010f2eac66 https://github.com/Linaro/odp/commit/c951ba0386581a87675477456e3df0010f2eac66 Author: Bill Fischofer Date: 2017-05-24 (Wed, 24 May 2017) Changed paths: M include/odp/api/spec/classification.h Log Message: --- api: classification: add additional doxygen documentation Resolve Bug https://bugs.linaro.org/show_bug.cgi?id=2952 by adding additional field documentation to avoid problems with doxygen 1.8.13 and higher. Signed-off-by: Bill Fischofer Reviewed-by: Petri Savolainen Signed-off-by: Maxim Uvarov
[lng-odp] [Bug 2952] doxygen errors and travis does not catch them
https://bugs.linaro.org/show_bug.cgi?id=2952 --- Comment #16 from Maxim Uvarov --- https://github.com/Linaro/odp/commit/c951ba0386581a87675477456e3df0010f2eac66 2017-05-24T22:29:07+03:00 Bill Fischofer bill.fischo...@linaro.org api: classification: add additional doxygen documentation Resolve Bug https://bugs.linaro.org/show_bug.cgi?id=2952 by adding additional field documentation to avoid problems with doxygen 1.8.13 and higher. Signed-off-by: Bill Fischofer Reviewed-by: Petri Savolainen Signed-off-by: Maxim Uvarov -- You are receiving this mail because: You are on the CC list for the bug.
[lng-odp] [Bug 2826] CID 174664: Unchecked return in pool.c
https://bugs.linaro.org/show_bug.cgi?id=2826 --- Comment #3 from Maxim Uvarov --- https://github.com/Linaro/odp/commit/88dbb00623102878f2e0e1dd720a942fdd980ca3 2017-03-02T18:00:12+03:00 Bill Fischofer bill.fischo...@linaro.org linux-generic: pool: add odp_pool_capability() rc check Resolve Bug https://bugs.linaro.org/show_bug.cgi?id=2826 by adding an explicit check of the rc from odp_pool_capability() for consistency with other code that calls this routine. Signed-off-by: Bill Fischofer Signed-off-by: Maxim Uvarov -- You are receiving this mail because: You are on the CC list for the bug.
[lng-odp] [Linaro/odp] 39f85b: helper: linux: add common linux helper file
Branch: refs/heads/next Home: https://github.com/Linaro/odp Commit: 39f85bc6cab329b4ae41ba2ec922370c24254325 https://github.com/Linaro/odp/commit/39f85bc6cab329b4ae41ba2ec922370c24254325 Author: Petri Savolainen Date: 2017-03-02 (Thu, 02 Mar 2017) Changed paths: M helper/Makefile.am A helper/include/odp/helper/linux.h Log Message: --- helper: linux: add common linux helper file Added common helper file for backwards compatibility. This file includes all headers under helper/linux directory. It's installed only with --enable-helper-linux configuration option. Signed-off-by: Petri Savolainen Reviewed-and-tested-by: Bill Fischofer Signed-off-by: Maxim Uvarov Commit: e93df7d7b3b278dfadba4a9b7c01afc0dd411f13 https://github.com/Linaro/odp/commit/e93df7d7b3b278dfadba4a9b7c01afc0dd411f13 Author: Petri Savolainen Date: 2017-03-02 (Thu, 02 Mar 2017) Changed paths: M configure.ac M helper/Makefile.am R pkgconfig/libodphelper-linux-generic.pc.in A pkgconfig/libodphelper.pc.in Log Message: --- helper: pkgconfig: remove linux-generic from helper lib name Helper library should be built ABI compatible when it's part of a distro. There's no need to have implementation specific helper libs. Those would be needed only if non-ABI compat helper libraries need to be distributed. Signed-off-by: Petri Savolainen Reviewed-and-tested-by: Bill Fischofer Signed-off-by: Maxim Uvarov Commit: 2bac2dbfd7a7c55e588a6b72af22ae7b810558f7 https://github.com/Linaro/odp/commit/2bac2dbfd7a7c55e588a6b72af22ae7b810558f7 Author: Petri Savolainen Date: 2017-03-02 (Thu, 02 Mar 2017) Changed paths: M DEPENDENCIES Log Message: --- linux-gen: dependencies: update cunit install instructions Add missing commands and update instructions for installing into default location for 'make distcheck'. Signed-off-by: Petri Savolainen Reviewed-and-tested-by: Bill Fischofer Signed-off-by: Maxim Uvarov Commit: 88dbb00623102878f2e0e1dd720a942fdd980ca3 https://github.com/Linaro/odp/commit/88dbb00623102878f2e0e1dd720a942fdd980ca3 Author: Bill Fischofer Date: 2017-03-02 (Thu, 02 Mar 2017) Changed paths: M platform/linux-generic/odp_pool.c Log Message: --- linux-generic: pool: add odp_pool_capability() rc check Resolve Bug https://bugs.linaro.org/show_bug.cgi?id=2826 by adding an explicit check of the rc from odp_pool_capability() for consistency with other code that calls this routine. Signed-off-by: Bill Fischofer Signed-off-by: Maxim Uvarov Commit: a347c91412f0db5c25141b709a93eaf040a77730 https://github.com/Linaro/odp/commit/a347c91412f0db5c25141b709a93eaf040a77730 Author: Matias Elo Date: 2017-03-02 (Thu, 02 Mar 2017) Changed paths: M platform/linux-generic/m4/odp_dpdk.m4 M platform/linux-generic/pktio/dpdk.c Log Message: --- linux-gen: dpdk: improve pmd driver linking Previously each dpdk pmd driver had to be individually referred in the odp code to ensure proper gcc constructor linking. Using the -—whole-archive option when linking the drivers removes this need. After this patch new dpdk pmd drivers are automatically linked. Signed-off-by: Matias Elo Signed-off-by: Maxim Uvarov Commit: e6a635ac73e99a9a7a6b499685a72139e87044ea https://github.com/Linaro/odp/commit/e6a635ac73e99a9a7a6b499685a72139e87044ea Author: Matias Elo Date: 2017-03-02 (Thu, 02 Mar 2017) Changed paths: M test/linux-generic/validation/api/pktio/pktio_run_dpdk.sh Log Message: --- linux-gen: dpdk: disable pci devices when running make check Disable pci devices during DPDK pktio validation test. If the system has pci devices mapped to DPDK pmd drivers they may overlap with the test vdev device indices, which will cause the validation test to fail. Signed-off-by: Matias Elo Signed-off-by: Maxim Uvarov Commit: 37db76d04174f90f86c8103e6a1ca9d1e9518098 https://github.com/Linaro/odp/commit/37db76d04174f90f86c8103e6a1ca9d1e9518098 Author: Matias Elo Date: 2017-03-02 (Thu, 02 Mar 2017) Changed paths: M .travis.yml M DEPENDENCIES M scripts/build-pktio-dpdk Log Message: --- linux-gen: dpdk: bump target dpdk version to 17.02 Signed-off-by: Matias Elo Signed-off-by: Maxim Uvarov Commit: ec8a54c9236925ea97ee154eb70093d6effb1311 https://github.com/Linaro/odp/commit/ec8a54c9236925ea97ee154eb70093d6effb1311 Author: Janne Peltonen Date: 2017-03-10 (Fri, 10 Mar 2017) Changed paths: M platform/linux-generic/Makefile.am Log Message: --- linux-gen: abi: fix include/odp/api/abi symlink creation Fix the ABI symlink creation that went broken in 3d6cbd2. Signed-off-by: Janne Peltonen Signed-off-by: Maxim Uvarov Commit: 746455fcdf279fcef7ec6a3eb6c5f1b465588554 https://github.com/Linaro/odp/commit/746455fcdf279fcef7ec6a3eb6c5f1b465588554
Re: [lng-odp] [PATCH v2 1/1] travis: use pkg-config to discover ODP flags
something like
--- a/pkgconfig/libodp-linux.pc.in
+++ b/pkgconfig/libodp-linux.pc.in
@@ -6,6 +6,6 @@ includedir=@includedir@
Name: libodp-linux
Description: The ODP packet processing engine
Version: @PKGCONFIG_VERSION@
-Libs: -L${libdir} -lodp-linux
+Libs: -L${libdir} -lodp-linux @LIBS@
Libs.private:
Cflags: -I${includedir}
is missing.
On 05/24/17 20:00, Github ODP bot wrote:
> From: Dmitry Eremin-Solenikov
>
> Signed-off-by: Dmitry Eremin-Solenikov
> ---
> /** Email created from pull request 38 (lumag:fix-link)
> ** https://github.com/Linaro/odp/pull/38
> ** Patch: https://github.com/Linaro/odp/pull/38.patch
> ** Base sha: ea134fe159c0d249e4bed12b7269e8236afa0262
> ** Merge commit sha: 2a43e1a78dacc9d3122ed0cd88edd811052d09c0
> **/
> .travis.yml | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/.travis.yml b/.travis.yml
> index 65edfbb3..8ef5637e 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -133,10 +133,10 @@ script:
> - echo "Checking linking and run from install..."
> - pushd $HOME
> - echo "Dynamic link.."
> -- ${CC} ${OLDPWD}/example/hello/odp_hello.c -o odp_hello_inst
> -I${HOME}/odp-install/include -L${HOME}/odp-install/lib -lodp-linux
> -L${OLDPWD}/dpdk/x86_64-native-linuxapp-gcc/lib -lrt -ldpdk -lpthread
> -lcrypto -lpcap $MY_CF $MY_LDF -ldl
> +- ${CC} ${OLDPWD}/example/hello/odp_hello.c -o odp_hello_inst
> `PKG_CONFIG_PATH=${HOME}/odp-install/lib/pkgconfig pkg-config --cflags --libs
> libodp-linux` $MY_CF $MY_LDF
> - LD_LIBRARY_PATH="${HOME}/odp-install/lib:$LD_LIBRARY_PATH"
> ./odp_hello_inst
> - echo "Static link.."
> -- ${CC} ${OLDPWD}/example/hello/odp_hello.c -o odp_hello_inst
> -I${HOME}/odp-install/include -L${HOME}/odp-install/lib -lodp-linux
> -L${OLDPWD}/dpdk/x86_64-native-linuxapp-gcc/lib -lrt -ldpdk -lpthread
> -lcrypto -lpcap $MY_CF $MY_LDF -ldl -static
> +- ${CC} ${OLDPWD}/example/hello/odp_hello.c -o odp_hello_inst
> `PKG_CONFIG_PATH=${HOME}/odp-install/lib/pkgconfig pkg-config --cflags --libs
> libodp-linux --static` $MY_CF $MY_LDF -static
> - ./odp_hello_inst
> - popd
>
>
[lng-odp] [PATCH v2 1/1] travis: use pkg-config to discover ODP flags
From: Dmitry Eremin-Solenikov
Signed-off-by: Dmitry Eremin-Solenikov
---
/** Email created from pull request 38 (lumag:fix-link)
** https://github.com/Linaro/odp/pull/38
** Patch: https://github.com/Linaro/odp/pull/38.patch
** Base sha: ea134fe159c0d249e4bed12b7269e8236afa0262
** Merge commit sha: 2a43e1a78dacc9d3122ed0cd88edd811052d09c0
**/
.travis.yml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 65edfbb3..8ef5637e 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -133,10 +133,10 @@ script:
- echo "Checking linking and run from install..."
- pushd $HOME
- echo "Dynamic link.."
-- ${CC} ${OLDPWD}/example/hello/odp_hello.c -o odp_hello_inst
-I${HOME}/odp-install/include -L${HOME}/odp-install/lib -lodp-linux
-L${OLDPWD}/dpdk/x86_64-native-linuxapp-gcc/lib -lrt -ldpdk -lpthread -lcrypto
-lpcap $MY_CF $MY_LDF -ldl
+- ${CC} ${OLDPWD}/example/hello/odp_hello.c -o odp_hello_inst
`PKG_CONFIG_PATH=${HOME}/odp-install/lib/pkgconfig pkg-config --cflags --libs
libodp-linux` $MY_CF $MY_LDF
- LD_LIBRARY_PATH="${HOME}/odp-install/lib:$LD_LIBRARY_PATH"
./odp_hello_inst
- echo "Static link.."
-- ${CC} ${OLDPWD}/example/hello/odp_hello.c -o odp_hello_inst
-I${HOME}/odp-install/include -L${HOME}/odp-install/lib -lodp-linux
-L${OLDPWD}/dpdk/x86_64-native-linuxapp-gcc/lib -lrt -ldpdk -lpthread -lcrypto
-lpcap $MY_CF $MY_LDF -ldl -static
+- ${CC} ${OLDPWD}/example/hello/odp_hello.c -o odp_hello_inst
`PKG_CONFIG_PATH=${HOME}/odp-install/lib/pkgconfig pkg-config --cflags --libs
libodp-linux --static` $MY_CF $MY_LDF -static
- ./odp_hello_inst
- popd
[lng-odp] [PATCH v2 0/1] travis: use pkg-config to discover ODP flags
Signed-off-by: Dmitry Eremin-Solenikov dmitry.ereminsoleni...@linaro.org github /** Email created from pull request 38 (lumag:fix-link) ** https://github.com/Linaro/odp/pull/38 ** Patch: https://github.com/Linaro/odp/pull/38.patch ** Base sha: ea134fe159c0d249e4bed12b7269e8236afa0262 ** Merge commit sha: 2a43e1a78dacc9d3122ed0cd88edd811052d09c0 **/ /github checkpatch.pl total: 0 errors, 0 warnings, 0 checks, 12 lines checked to_send-p-000.patch has no obvious style problems and is ready for submission. /checkpatch.pl
[lng-odp] [PATCH v1 1/1] travis: use pkg-config to discover ODP flags
From: Dmitry Eremin-Solenikov
Signed-off-by: Dmitry Eremin-Solenikov
---
/** Email created from pull request 38 (lumag:fix-link)
** https://github.com/Linaro/odp/pull/38
** Patch: https://github.com/Linaro/odp/pull/38.patch
** Base sha: ea134fe159c0d249e4bed12b7269e8236afa0262
** Merge commit sha: f031f4f42208491058f3e37b996d067658737abc
**/
.travis.yml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 65edfbb3..3d7945ed 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -133,10 +133,10 @@ script:
- echo "Checking linking and run from install..."
- pushd $HOME
- echo "Dynamic link.."
-- ${CC} ${OLDPWD}/example/hello/odp_hello.c -o odp_hello_inst
-I${HOME}/odp-install/include -L${HOME}/odp-install/lib -lodp-linux
-L${OLDPWD}/dpdk/x86_64-native-linuxapp-gcc/lib -lrt -ldpdk -lpthread -lcrypto
-lpcap $MY_CF $MY_LDF -ldl
+- PKG_CONFIG_PATH=${HOME}/odp-install/lib/pkgconfig ${CC}
${OLDPWD}/example/hello/odp_hello.c -o odp_hello_inst `pkg-config --cflags
--libs libodp-linux` $MY_CF $MY_LDF
- LD_LIBRARY_PATH="${HOME}/odp-install/lib:$LD_LIBRARY_PATH"
./odp_hello_inst
- echo "Static link.."
-- ${CC} ${OLDPWD}/example/hello/odp_hello.c -o odp_hello_inst
-I${HOME}/odp-install/include -L${HOME}/odp-install/lib -lodp-linux
-L${OLDPWD}/dpdk/x86_64-native-linuxapp-gcc/lib -lrt -ldpdk -lpthread -lcrypto
-lpcap $MY_CF $MY_LDF -ldl -static
+- PKG_CONFIG_PATH=${HOME}/odp-install/lib/pkgconfig ${CC}
${OLDPWD}/example/hello/odp_hello.c -o odp_hello_inst `pkg-config --cflags
--libs libodp-linux --static` $MY_CF $MY_LDF -static
- ./odp_hello_inst
- popd
[lng-odp] [PATCH v1 0/1] travis: use pkg-config to discover ODP flags
Signed-off-by: Dmitry Eremin-Solenikov dmitry.ereminsoleni...@linaro.org github /** Email created from pull request 38 (lumag:fix-link) ** https://github.com/Linaro/odp/pull/38 ** Patch: https://github.com/Linaro/odp/pull/38.patch ** Base sha: ea134fe159c0d249e4bed12b7269e8236afa0262 ** Merge commit sha: f031f4f42208491058f3e37b996d067658737abc **/ /github checkpatch.pl total: 0 errors, 0 warnings, 0 checks, 12 lines checked to_send-p-000.patch has no obvious style problems and is ready for submission. /checkpatch.pl
Re: [lng-odp] APIs for dealing with compact handles
Given the assumptions that VPP makes on packet / pool organization,
perhaps another approach would be to add a request bit to the
odp_pool_param_t struct to request that this pool support linear
organization.
Something like:
typedef struct odp_pool_param_t {
/** Pool type */
int type;
union {
uint32_t all_bits;
struct {
uint32_t linear:1;
};
} opts;
/** Variant parameters for different pool types */
union {
...
};
} odp_pool_param_t;
Setting param.opts.linear would request that this pool be organized
such that applications like VPP can do the math it's currently doing?
We could also provide "official" APIs to create/expand compact handles
and encourage apps to make use of those since not every implementation
may be able to offer linear pools. Specifying the linear option on
such an implementation would result in the odp_pool_create() call
failing.
On Wed, May 24, 2017 at 7:21 AM, Bill Fischofer
wrote:
> I've added this topic to the agenda for today's ARCH call. I agree
> with Petri that any changes should be based on measurements, and
> preferably real application measurements rather than microbenchmarks.
>
> On Wed, May 24, 2017 at 6:46 AM, Savolainen, Petri (Nokia - FI/Espoo)
> wrote:
>>
>>
>>> -Original Message-
>>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>>> Sachin Saxena
>>> Sent: Wednesday, May 24, 2017 12:43 PM
>>> To: lng-odp@lists.linaro.org
>>> Subject: Re: [lng-odp] APIs for dealing with compact handles
>>>
>>> Thanks Bill for initiating the thread.
>>>
>>> Please checkout some more details*(**i**nline)* on the requirements &
>>> proposal.
>>>
>>>
>>> On 5/17/2017 8:50 PM, Bill Fischofer wrote:
>>> > This thread is to discuss ideas and proposed solutions to two issues
>>> > that have been raised by Sachin relating to VPP needs, as well as
>>> > Honnappa relating to the scalable scheduler. Background = ODP
>>> > handles are abstract types that implementations may define to be of
>>> > arbitrary bit width in size. However, for a number of reasons (e.g.,
>>> > provision of strong typing support, ABI compatibility, efficiency of
>>> > internal manipulation, etc.) these are typically represented as 64-bit
>>> > quantities. Some applications that store handles in their own
>>> > structures wish to minimize the cache footprint consumed by these
>>> > structures and so would like an option to store handles in a more
>>> > compact format that uses a smaller number of bits. To date 32-bits
>>> > seems sufficient for application need, however in theory 16 or even 8
>>> > bits might be desirable in some circumstances. We already have an
>>> > example of 8-bit handles in the odp_packet_seg_t type, where odp-linux
>>> > uses an 8-bit representation of this type as a segment index when ODP
>>> > is configured with --enable-abi-compat=no while using a 64-bit size
>>> > when configured with --enable-abi-compat=yes. Considerations
>>> > In choosing the bit width to use in representing handles
>>> > there are two main considerations that implementations must take into
>>> > account. First, to achieve strong typing in C, handles need to be of
>>> > pointer width. For development this is a very valuable feature, which
>>> > is why implementations are encouraged to provide strong typing for ODP
>>> > abstract types. Second, for ABI compatibility it is required that all
>>> > implementations use the same width for types that are to be ABI
>>> > compatible across different implementations. Implementations may
>>> > interpret the bits of a handle very differently, but all must agree
>>> > that handles are of the same bit width if they wish to be binary
>>> > compatible with each other. Stated Needs === VPP currently
>>> > packages its metadata into a vlib_mbuf struct that is used pervasively
>>> > to reference packets that are being processed by VPP nodes. The
>>> > address of this struct is desired to be held in compressed (32-bit)
>>> > format. Today the vlib_mbuf is implemented as a user area associated
>>> > with an odp_packet_t. As such the odp_packet_user_area() API returns a
>>> > (64-bit) pointer. What is desired is a compact representation of this
>>> > address.
>>> VPP collects bunch of packets from ODP/DPDK input node and looks for
>>> inline "struct vlib_buffer" address in each packet.
>>> Then it creates a VPP Library Frame which is a collection of the
>>> vlib_buffers (vectors). For this, VPP converts 64-bit address of each
>>> vlib_buffer to a 32-bit index and save in the VLib frame and pass this
>>> frame to next Node.
>>> In each processing node in Data path where packet contents are accessed,
>>> VPP converts this 32-bit index to actual 64-bit address to get packet
>>> data pointer.
>>> In current implementation, VPP converts 32-bit index to address @ ~900
>>> places in overall code via A
[lng-odp] [PATCH API-NEXT v1 1/1] api: crypto: make odp_crypto_session_create return odp_crypto_session_t
From: Dmitry Eremin-Solenikov
Currently odp_crypto_session_create() (unlike other creation functions)
returns int result with session being returned through pointer argument.
Instead it is simpler to directly return a session (or
ODP_CRYPTO_SESSION_INVALID in case of an error).
Signed-off-by: Dmitry Eremin-Solenikov
---
/** Email created from pull request 37 (lumag:crypto-create-ret)
** https://github.com/Linaro/odp/pull/37
** Patch: https://github.com/Linaro/odp/pull/37.patch
** Base sha: f20dee9db3da9425d8764e414b04cdcbd41bece8
** Merge commit sha: 8238aaf85af493307ef6ff940a32f98c436137bf
**/
example/ipsec/odp_ipsec_cache.c| 4 +-
include/odp/api/spec/crypto.h | 12 ++--
platform/linux-generic/odp_crypto.c| 14 ++---
test/common_plat/performance/odp_crypto.c | 68 +++---
.../validation/api/crypto/odp_crypto_test_inp.c| 7 +--
5 files changed, 51 insertions(+), 54 deletions(-)
diff --git a/example/ipsec/odp_ipsec_cache.c b/example/ipsec/odp_ipsec_cache.c
index b2a91c24..15617bc7 100644
--- a/example/ipsec/odp_ipsec_cache.c
+++ b/example/ipsec/odp_ipsec_cache.c
@@ -114,8 +114,8 @@ int create_ipsec_cache_entry(sa_db_entry_t *cipher_sa,
return -1;
}
- /* Synchronous session create for now */
- if (odp_crypto_session_create(¶ms, &session, &ses_create_rc))
+ session = odp_crypto_session_create(¶ms, &ses_create_rc);
+ if (ODP_CRYPTO_SESSION_INVALID == session)
return -1;
if (ODP_CRYPTO_SES_CREATE_ERR_NONE != ses_create_rc)
return -1;
diff --git a/include/odp/api/spec/crypto.h b/include/odp/api/spec/crypto.h
index c47d3149..493e17f7 100644
--- a/include/odp/api/spec/crypto.h
+++ b/include/odp/api/spec/crypto.h
@@ -585,15 +585,15 @@ int odp_crypto_auth_capability(odp_auth_alg_t auth,
* default values.
*
* @param param Session parameters
- * @param session Created session else ODP_CRYPTO_SESSION_INVALID
* @param statusFailure code if unsuccessful
*
- * @retval 0 on success
- * @retval <0 on failure
+ * @retval created session on success
+ * @retval ODP_CRYPTO_SESSION_INVALID on failure
*/
-int odp_crypto_session_create(odp_crypto_session_param_t *param,
- odp_crypto_session_t *session,
- odp_crypto_ses_create_err_t *status);
+odp_crypto_session_t odp_crypto_session_create(odp_crypto_session_param_t
+ *param,
+ odp_crypto_ses_create_err_t
+ *status);
/**
* Crypto session destroy
diff --git a/platform/linux-generic/odp_crypto.c
b/platform/linux-generic/odp_crypto.c
index a993542f..11d3af3a 100644
--- a/platform/linux-generic/odp_crypto.c
+++ b/platform/linux-generic/odp_crypto.c
@@ -656,9 +656,8 @@ int odp_crypto_auth_capability(odp_auth_alg_t auth,
return num;
}
-int
+odp_crypto_session_t
odp_crypto_session_create(odp_crypto_session_param_t *param,
- odp_crypto_session_t *session_out,
odp_crypto_ses_create_err_t *status)
{
int rc;
@@ -672,7 +671,7 @@ odp_crypto_session_create(odp_crypto_session_param_t *param,
session = alloc_session();
if (NULL == session) {
*status = ODP_CRYPTO_SES_CREATE_ERR_ENOMEM;
- return -1;
+ return ODP_CRYPTO_SESSION_INVALID;
}
/* Copy parameters */
@@ -683,7 +682,7 @@ odp_crypto_session_create(odp_crypto_session_param_t *param,
if (session->p.iv.length > MAX_IV_LEN) {
ODP_DBG("Maximum IV length exceeded\n");
free_session(session);
- return -1;
+ return ODP_CRYPTO_SESSION_INVALID;
}
memcpy(session->cipher.iv_data, session->p.iv.data,
@@ -734,7 +733,7 @@ odp_crypto_session_create(odp_crypto_session_param_t *param,
if (rc) {
*status = ODP_CRYPTO_SES_CREATE_ERR_INV_CIPHER;
free_session(session);
- return -1;
+ return ODP_CRYPTO_SESSION_INVALID;
}
aes_gcm = 0;
@@ -781,12 +780,11 @@ odp_crypto_session_create(odp_crypto_session_param_t
*param,
if (rc) {
*status = ODP_CRYPTO_SES_CREATE_ERR_INV_AUTH;
free_session(session);
- return -1;
+ return ODP_CRYPTO_SESSION_INVALID;
}
/* We're happy */
- *session_out = (intptr_t)session;
- return 0;
+ return (odp_crypto_session_t)(intptr_t)session;
}
int odp_crypto_session_destroy(odp_crypto_session_t session)
diff --git a/test/common_plat/performance/odp_crypto.c
b/test/common_plat/performance/odp_crypto.c
index b3857973..95cc141c 100644
--- a/test
[lng-odp] [PATCH API-NEXT v1 0/1] api: crypto: make odp_crypto_session_create return odp_crypto_session_t
Currently odp_crypto_session_create() (unlike other creation functions) returns int result with session being returned through pointer argument. Instead it is simpler to directly return a session (or ODP_CRYPTO_SESSION_INVALID in case of an error). Signed-off-by: Dmitry Eremin-Solenikov dmitry.ereminsoleni...@linaro.org github /** Email created from pull request 37 (lumag:crypto-create-ret) ** https://github.com/Linaro/odp/pull/37 ** Patch: https://github.com/Linaro/odp/pull/37.patch ** Base sha: f20dee9db3da9425d8764e414b04cdcbd41bece8 ** Merge commit sha: 8238aaf85af493307ef6ff940a32f98c436137bf **/ /github checkpatch.pl total: 0 errors, 0 warnings, 0 checks, 202 lines checked to_send-p-000.patch has no obvious style problems and is ready for submission. /checkpatch.pl
[lng-odp] [Linaro/odp] ea134f: test: generator: replace gettimeofday with ODP API...
Branch: refs/heads/master Home: https://github.com/Linaro/odp Commit: ea134fe159c0d249e4bed12b7269e8236afa0262 https://github.com/Linaro/odp/commit/ea134fe159c0d249e4bed12b7269e8236afa0262 Author: Bogdan Pricope Date: 2017-05-24 (Wed, 24 May 2017) Changed paths: M example/generator/odp_generator.c Log Message: --- test: generator: replace gettimeofday with ODP API calls Fixes: https://bugs.linaro.org/show_bug.cgi?id=2416 Signed-off-by: Bogdan Pricope Reviewed-and-tested-by: Yi He Signed-off-by: Maxim Uvarov
Re: [lng-odp] [PATCH 0/3] Fix pktio with single segment packet pool
if it is useful case let's add this test to .travis.yaml Maxim. On 24 May 2017 at 17:35, Matias Elo wrote: > This patch set enables using packet pool in single segment mode > (CONFIG_PACKET_MAX_SEGS = 1). > > Matias Elo (3): > linux-gen: packet: fix odp_packet_free_multi() with single segment > pool > linux-gen: packet: fix gcc errors with single segment pool > test: pktio: use capability to set test pool packet length > > platform/linux-generic/odp_packet.c | 16 +++- > test/common_plat/validation/api/pktio/pktio.c | 7 +-- > 2 files changed, 16 insertions(+), 7 deletions(-) > > -- > 2.7.4 > >
[lng-odp] [PATCH 3/3] test: pktio: use capability to set test pool packet length
Test used to fail if odp_pool_capability_t.pkt.max_len < PKT_BUF_SIZE.
Signed-off-by: Matias Elo
---
test/common_plat/validation/api/pktio/pktio.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/test/common_plat/validation/api/pktio/pktio.c
b/test/common_plat/validation/api/pktio/pktio.c
index 54f206e..11fe974 100644
--- a/test/common_plat/validation/api/pktio/pktio.c
+++ b/test/common_plat/validation/api/pktio/pktio.c
@@ -122,20 +122,23 @@ static inline void _pktio_wait_linkup(odp_pktio_t pktio)
static void set_pool_len(odp_pool_param_t *params, odp_pool_capability_t *capa)
{
+ uint32_t len;
uint32_t seg_len;
+ len = (capa->pkt.max_len && capa->pkt.max_len < PKT_BUF_SIZE) ?
+ capa->pkt.max_len : PKT_BUF_SIZE;
seg_len = capa->pkt.max_seg_len ? capa->pkt.max_seg_len : PKT_BUF_SIZE;
switch (pool_segmentation) {
case PKT_POOL_SEGMENTED:
/* Force segment to minimum size */
params->pkt.seg_len = 0;
- params->pkt.len = PKT_BUF_SIZE;
+ params->pkt.len = len;
break;
case PKT_POOL_UNSEGMENTED:
default:
params->pkt.seg_len = seg_len;
- params->pkt.len = PKT_BUF_SIZE;
+ params->pkt.len = len;
break;
}
}
--
2.7.4
[lng-odp] [PATCH 2/3] linux-gen: packet: fix gcc errors with single segment pool
Fix (invalid) gcc errors when CONFIG_PACKET_MAX_SEGS is set to one.
Signed-off-by: Matias Elo
---
platform/linux-generic/odp_packet.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/platform/linux-generic/odp_packet.c
b/platform/linux-generic/odp_packet.c
index 3e7c07a..e2bb842 100644
--- a/platform/linux-generic/odp_packet.c
+++ b/platform/linux-generic/odp_packet.c
@@ -804,7 +804,8 @@ static inline int move_data_to_head(odp_packet_hdr_t
*pkt_hdr, int segs)
free_len = BASE_LEN - len;
- for (src_seg = dst_seg + 1; src_seg < segs; src_seg++) {
+ for (src_seg = dst_seg + 1; CONFIG_PACKET_MAX_SEGS > 1 &&
+src_seg < segs; src_seg++) {
len = fill_seg_head(pkt_hdr, dst_seg, src_seg,
free_len);
moved += len;
@@ -928,7 +929,7 @@ int odp_packet_extend_head(odp_packet_t *pkt, uint32_t len,
pkt_hdr = new_hdr;
*pkt= packet_handle(pkt_hdr);
- } else if (free_segs) {
+ } else if (CONFIG_PACKET_MAX_SEGS > 1 && free_segs) {
new_hdr = pkt_hdr->buf_hdr.seg[free_segs].hdr;
packet_seg_copy_md(new_hdr, pkt_hdr);
--
2.7.4
[lng-odp] [PATCH 1/3] linux-gen: packet: fix odp_packet_free_multi() with single segment pool
Previously the implementation would use wrong handles and crash if
CONFIG_PACKET_MAX_SEGS was set to one.
Signed-off-by: Matias Elo
---
platform/linux-generic/odp_packet.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/platform/linux-generic/odp_packet.c
b/platform/linux-generic/odp_packet.c
index e99e8b8..3e7c07a 100644
--- a/platform/linux-generic/odp_packet.c
+++ b/platform/linux-generic/odp_packet.c
@@ -594,11 +594,16 @@ void odp_packet_free(odp_packet_t pkt)
void odp_packet_free_multi(const odp_packet_t pkt[], int num)
{
+ odp_buffer_t buf[num * CONFIG_PACKET_MAX_SEGS];
+ int i;
+
if (CONFIG_PACKET_MAX_SEGS == 1) {
- buffer_free_multi((const odp_buffer_t * const)pkt, num);
+ for (i = 0; i < num; i++)
+ buf[i] = buffer_handle(packet_hdr(pkt[i]));
+
+ buffer_free_multi(buf, num);
} else {
- odp_buffer_t buf[num * CONFIG_PACKET_MAX_SEGS];
- int i, j;
+ int j;
int bufs = 0;
for (i = 0; i < num; i++) {
--
2.7.4
[lng-odp] [PATCH 0/3] Fix pktio with single segment packet pool
This patch set enables using packet pool in single segment mode (CONFIG_PACKET_MAX_SEGS = 1). Matias Elo (3): linux-gen: packet: fix odp_packet_free_multi() with single segment pool linux-gen: packet: fix gcc errors with single segment pool test: pktio: use capability to set test pool packet length platform/linux-generic/odp_packet.c | 16 +++- test/common_plat/validation/api/pktio/pktio.c | 7 +-- 2 files changed, 16 insertions(+), 7 deletions(-) -- 2.7.4
[lng-odp] [Bug 3002] Packet order lost when enqueuing to pktout queue
https://bugs.linaro.org/show_bug.cgi?id=3002 --- Comment #1 from Maxim Uvarov --- https://github.com/Linaro/odp/commit/60b9dd435bf1be55794e5be6ee24714d28a5b587 2017-05-23T23:14:36+03:00 Matias Elo matias@nokia.com linux-gen: sched: fix ordered enqueue to pktout queue Make sure packet order is maintained if enqueueing packets from an ordered queue. Fixes https://bugs.linaro.org/show_bug.cgi?id=3002 Signed-off-by: Matias Elo Reviewed-and-tested-by: Yi He Signed-off-by: Maxim Uvarov -- You are receiving this mail because: You are on the CC list for the bug.
[lng-odp] [Linaro/odp] 60b9dd: linux-gen: sched: fix ordered enqueue to pktout qu...
Branch: refs/heads/master Home: https://github.com/Linaro/odp Commit: 60b9dd435bf1be55794e5be6ee24714d28a5b587 https://github.com/Linaro/odp/commit/60b9dd435bf1be55794e5be6ee24714d28a5b587 Author: Matias Elo Date: 2017-05-23 (Tue, 23 May 2017) Changed paths: M platform/linux-generic/odp_packet_io.c M platform/linux-generic/odp_queue.c M platform/linux-generic/odp_schedule.c M platform/linux-generic/odp_schedule_iquery.c Log Message: --- linux-gen: sched: fix ordered enqueue to pktout queue Make sure packet order is maintained if enqueueing packets from an ordered queue. Fixes https://bugs.linaro.org/show_bug.cgi?id=3002 Signed-off-by: Matias Elo Reviewed-and-tested-by: Yi He Signed-off-by: Maxim Uvarov
Re: [lng-odp] Summary of Expiration Discussion
Bill Fischofer wrote: > > The following data items MUST be in the SAD: But that does not necessarily mean that they need to be in the ODP SA. > With this background, it's clear that should we choose to remove > time-based expiration from the ODP IPsec API spec we would have an > incomplete IPsec specification that would require any ODP > implementation that wishes to be IPsec compliant to "fill in" the spec > on its own. That would not be good. Regardless of how complete the life time support is in ODP, there are other things that the application needs to do for IPsec RFC compliancy. For example, ODP does not do any policy enforcement but leaves it to the application (which is good since it adds flexibility). > Note also that the RFC says > nothing about counting packets, only bytes, so perhaps we shouldn't be > offering packet counts? I suppose packet based life times could be added later as a backward compatible API change if they are not included now. But I think some other IPsec implementations provide them. > Given that we want to keep these, the question is then how are they to > be handled? The argument I would make is that these are control > signals as they indicate that the control plane should begin rekeying > on an SA (soft expiration) or that an SA's lifetime has ended (hard > expiration). As such they should be odp_ipsec_status_t events, which > seems to be what IPsec users like OFP would prefer. Even if all life time expirations are signaled as status events, a normal operation completion event for a packet is needed when IPsec processing is attempted but fails due to hard life time (or byte or packet limit) expiration. So those error bits are still needed in the op_result. I am not sure OFP has any preference one way or the other. > But perhaps this is too coarse. Having a dest_cos makes sense for > PIPELINE_CLS output but the current dest_queue is used for both > odp_ipsec_result_t and odp_ipsec_status_t events, which inherently > have different "consumers". So might it make more sense to split this > into: > > /** > * Output queue for IPSEC results > * > * Operations in asynchronous or inline mode enqueue result events are placed > * onto this queue. > */ > odp_queue_t result_queue; > > /** > * Output queue for IPSEC status > * > * Status events relating to this SA are placed onto this queue. > */ > odp_queue_t status_queue; There are some status events (at least the disable SA completion event) that need to be ordered with operation completion events. When an application gets the disable completion event, it must be able to count on that it has seen all operation completion events for that SA or else it becomes much more difficult to tear down SAs safely. To get that ordering, disable completion needs to come through the same queue as the normal IPsec operation events. This ordering is not currently explicitly specified in the API but we have discussed the need to clarify the API with Petri. I think the ordering becomes even more important if we change operation result events to packet events with IPsec specific packet metadata. Janne
Re: [lng-odp] APIs for dealing with compact handles
I've added this topic to the agenda for today's ARCH call. I agree with Petri that any changes should be based on measurements, and preferably real application measurements rather than microbenchmarks. On Wed, May 24, 2017 at 6:46 AM, Savolainen, Petri (Nokia - FI/Espoo) wrote: > > >> -Original Message- >> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of >> Sachin Saxena >> Sent: Wednesday, May 24, 2017 12:43 PM >> To: lng-odp@lists.linaro.org >> Subject: Re: [lng-odp] APIs for dealing with compact handles >> >> Thanks Bill for initiating the thread. >> >> Please checkout some more details*(**i**nline)* on the requirements & >> proposal. >> >> >> On 5/17/2017 8:50 PM, Bill Fischofer wrote: >> > This thread is to discuss ideas and proposed solutions to two issues >> > that have been raised by Sachin relating to VPP needs, as well as >> > Honnappa relating to the scalable scheduler. Background = ODP >> > handles are abstract types that implementations may define to be of >> > arbitrary bit width in size. However, for a number of reasons (e.g., >> > provision of strong typing support, ABI compatibility, efficiency of >> > internal manipulation, etc.) these are typically represented as 64-bit >> > quantities. Some applications that store handles in their own >> > structures wish to minimize the cache footprint consumed by these >> > structures and so would like an option to store handles in a more >> > compact format that uses a smaller number of bits. To date 32-bits >> > seems sufficient for application need, however in theory 16 or even 8 >> > bits might be desirable in some circumstances. We already have an >> > example of 8-bit handles in the odp_packet_seg_t type, where odp-linux >> > uses an 8-bit representation of this type as a segment index when ODP >> > is configured with --enable-abi-compat=no while using a 64-bit size >> > when configured with --enable-abi-compat=yes. Considerations >> > In choosing the bit width to use in representing handles >> > there are two main considerations that implementations must take into >> > account. First, to achieve strong typing in C, handles need to be of >> > pointer width. For development this is a very valuable feature, which >> > is why implementations are encouraged to provide strong typing for ODP >> > abstract types. Second, for ABI compatibility it is required that all >> > implementations use the same width for types that are to be ABI >> > compatible across different implementations. Implementations may >> > interpret the bits of a handle very differently, but all must agree >> > that handles are of the same bit width if they wish to be binary >> > compatible with each other. Stated Needs === VPP currently >> > packages its metadata into a vlib_mbuf struct that is used pervasively >> > to reference packets that are being processed by VPP nodes. The >> > address of this struct is desired to be held in compressed (32-bit) >> > format. Today the vlib_mbuf is implemented as a user area associated >> > with an odp_packet_t. As such the odp_packet_user_area() API returns a >> > (64-bit) pointer. What is desired is a compact representation of this >> > address. >> VPP collects bunch of packets from ODP/DPDK input node and looks for >> inline "struct vlib_buffer" address in each packet. >> Then it creates a VPP Library Frame which is a collection of the >> vlib_buffers (vectors). For this, VPP converts 64-bit address of each >> vlib_buffer to a 32-bit index and save in the VLib frame and pass this >> frame to next Node. >> In each processing node in Data path where packet contents are accessed, >> VPP converts this 32-bit index to actual 64-bit address to get packet >> data pointer. >> In current implementation, VPP converts 32-bit index to address @ ~900 >> places in overall code via API: >> vlib_get_buffer (vlib_main_t * vm, u32 buffer_index) >> >> >> *Code reference*: >> GIT: https://git.fd.io/odp4vpp/log/ >> Files: vlib/vlib/buffer_funcs.h >> vlib/vlib/buffer.h > > > Have you considered / tested the performance impact of changing buffer_index > to u64. Surely, you can now pack more u32 indexes per cache line, but you > need to do the conversion many times (900 places hints that it's done > multiple times per a forwarded packet) which consumes CPU cycles also. I'd > like to get some numbers, how much better of you are with 32bit vs 64bit > handles. 64 bit handles would remove need for conversions on both levels - > application or ODP would not need to convert as application would store > odp_packet_t, which would be direct pointer to packet structure. E.g. HW data > prefetchers may have improved from the time when VPP was originally designed. > > If <64bit indexes are needed, only viable option to me is packet index > conversion API (no user area indexes). The down side of it is that every > implementation must be able to do those conversions (efficiently). Also I'
Re: [lng-odp] [RFCv4] dpdk: enable hardware checksum support
> On 24 May 2017, at 11:32, Bogdan Pricope wrote:
>
> Hi Matias,
>
> Using ptypes reported by dpdk in parser was intended for another patch
> (next work after csum).
>
Good, so we are on the same page. When implementing packet parsing you have to
move/reimplement this checksum code anyway, so it makes more sense to implement
both of them in the same patch / patch set.
> I guess your test is a degradation test (due to new ifs) and you did
> not enabled csum offloads/ set flags on packets.
Yep, just standard l2fwd test without any offload flags.
>
> What will be interesting to see:
> - in a generation or termination test (UDP), what will be
> degradation/gain with csum offload enabled
> - how degradation/gain is changing with bigger packets (256 bytes vs 64 bytes)
That would definitely be more interesting. I tried quickly enabling
'ipv4_chksum'
and 'udp_chksum' flags on odp_l2fwd and the performance degradation was minimal
(~0.2%).
While testing this I noticed a small problem in the code:
> + ptype_cnt = rte_eth_dev_get_supported_ptypes(pkt_dpdk->port_id,
> +
>ptype_mask, ptypes, ptype_cnt);
> + for (i = 0; i < ptype_cnt; i++)
> + switch (ptypes[i]) {
> + case RTE_PTYPE_L3_IPV4:
> + ptype_l3_ipv4 = 1;
> + break;
> + case RTE_PTYPE_L4_TCP:
> + ptype_l4_tcp = 1;
> + break;
> + case RTE_PTYPE_L4_UDP:
> + ptype_l4_udp = 1;
> + break;
> + }
> + }
This doesn't work alone in all cases. For example Fortville NIC uses
RTE_PTYPE_L3_IPV4_EXT_UNKNOWN but not RTE_PTYPE_L3_IPV4.
-Matias
Re: [lng-odp] [API-NEXT PATCH v6 3/6] Add arch/ files
> -Original Message- > From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@linaro.org] > Sent: Wednesday, May 24, 2017 6:59 AM > To: Savolainen, Petri (Nokia - FI/Espoo) > Cc: Brian Brooks ; lng-odp@lists.linaro.org; Ola > Liljedahl > Subject: Re: [lng-odp] [API-NEXT PATCH v6 3/6] Add arch/ files > > On 23 May 2017 at 02:10, Savolainen, Petri (Nokia - FI/Espoo) > wrote: > >> diff --git a/platform/linux-generic/arch/powerpc/odp_cpu.h > >> b/platform/linux-generic/arch/powerpc/odp_cpu.h > >> new file mode 100644 > >> index ..e118e709 > >> --- /dev/null > >> +++ b/platform/linux-generic/arch/powerpc/odp_cpu.h > >> @@ -0,0 +1,10 @@ > >> +/* Copyright (c) 2017, Linaro Limited > >> + * All rights reserved. > >> + * > >> + * SPDX-License-Identifier: BSD-3-Clause > >> + */ > >> + > >> +#ifndef ODP_POWERPC_CPU_H_ > >> +#define ODP_POWERPC_CPU_H_ > >> + > >> +#endif > > > > > > Does this patch break build for all other archs but arm and x86? > Shouldn't you do the same (dummy) definitions for all architectures, as > you do for x86? > > > > Odp-linux should be usable in any system that runs Linux. It's not > practical to test on every arch, but we should always offer the default > code path that builds and should work fine on any arch. For example, I did > cross compile my latest x86 specific changes for PowerPC to see that a > non-x86 path also builds. > > > > We do not have the environment to compile for PowerPC or MIPS. Even if > we write dummy functions, we will not be able to compile the code for > those targets. During our earlier discussions, there was an agreement > that we will not do this for PowerPC or MIPS. Respective arch owners > have to create those functions. ODP dependencies file have some instructions for cross compiling. With Ubuntu you just need to install some extra packages. E.g. sudo apt-get install gcc-powerpc-linux-gnu So, you have the environment to build for e.g. PowerPC. Since odp-linux is for everybody (not only x86 and arm), you must not break the build for others. You may offer the minimal support, dummy functions, something that is functionally correct but not optimized - but you must not break the build. -Petri
Re: [lng-odp] APIs for dealing with compact handles
> -Original Message- > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of > Sachin Saxena > Sent: Wednesday, May 24, 2017 12:43 PM > To: lng-odp@lists.linaro.org > Subject: Re: [lng-odp] APIs for dealing with compact handles > > Thanks Bill for initiating the thread. > > Please checkout some more details*(**i**nline)* on the requirements & > proposal. > > > On 5/17/2017 8:50 PM, Bill Fischofer wrote: > > This thread is to discuss ideas and proposed solutions to two issues > > that have been raised by Sachin relating to VPP needs, as well as > > Honnappa relating to the scalable scheduler. Background = ODP > > handles are abstract types that implementations may define to be of > > arbitrary bit width in size. However, for a number of reasons (e.g., > > provision of strong typing support, ABI compatibility, efficiency of > > internal manipulation, etc.) these are typically represented as 64-bit > > quantities. Some applications that store handles in their own > > structures wish to minimize the cache footprint consumed by these > > structures and so would like an option to store handles in a more > > compact format that uses a smaller number of bits. To date 32-bits > > seems sufficient for application need, however in theory 16 or even 8 > > bits might be desirable in some circumstances. We already have an > > example of 8-bit handles in the odp_packet_seg_t type, where odp-linux > > uses an 8-bit representation of this type as a segment index when ODP > > is configured with --enable-abi-compat=no while using a 64-bit size > > when configured with --enable-abi-compat=yes. Considerations > > In choosing the bit width to use in representing handles > > there are two main considerations that implementations must take into > > account. First, to achieve strong typing in C, handles need to be of > > pointer width. For development this is a very valuable feature, which > > is why implementations are encouraged to provide strong typing for ODP > > abstract types. Second, for ABI compatibility it is required that all > > implementations use the same width for types that are to be ABI > > compatible across different implementations. Implementations may > > interpret the bits of a handle very differently, but all must agree > > that handles are of the same bit width if they wish to be binary > > compatible with each other. Stated Needs === VPP currently > > packages its metadata into a vlib_mbuf struct that is used pervasively > > to reference packets that are being processed by VPP nodes. The > > address of this struct is desired to be held in compressed (32-bit) > > format. Today the vlib_mbuf is implemented as a user area associated > > with an odp_packet_t. As such the odp_packet_user_area() API returns a > > (64-bit) pointer. What is desired is a compact representation of this > > address. > VPP collects bunch of packets from ODP/DPDK input node and looks for > inline "struct vlib_buffer" address in each packet. > Then it creates a VPP Library Frame which is a collection of the > vlib_buffers (vectors). For this, VPP converts 64-bit address of each > vlib_buffer to a 32-bit index and save in the VLib frame and pass this > frame to next Node. > In each processing node in Data path where packet contents are accessed, > VPP converts this 32-bit index to actual 64-bit address to get packet > data pointer. > In current implementation, VPP converts 32-bit index to address @ ~900 > places in overall code via API: > vlib_get_buffer (vlib_main_t * vm, u32 buffer_index) > > > *Code reference*: > GIT: https://git.fd.io/odp4vpp/log/ > Files: vlib/vlib/buffer_funcs.h > vlib/vlib/buffer.h Have you considered / tested the performance impact of changing buffer_index to u64. Surely, you can now pack more u32 indexes per cache line, but you need to do the conversion many times (900 places hints that it's done multiple times per a forwarded packet) which consumes CPU cycles also. I'd like to get some numbers, how much better of you are with 32bit vs 64bit handles. 64 bit handles would remove need for conversions on both levels - application or ODP would not need to convert as application would store odp_packet_t, which would be direct pointer to packet structure. E.g. HW data prefetchers may have improved from the time when VPP was originally designed. If <64bit indexes are needed, only viable option to me is packet index conversion API (no user area indexes). The down side of it is that every implementation must be able to do those conversions (efficiently). Also I'd say that index size would need to be 32 bits, so memory savings would be only 2x in a 64 bit system. Odp-linux used to define odp_packet_t as 32bit index, but was changed to pointer since it improved performance with l2fwd app about 10%. L2fwd is kind of worst case app since has very few cycles per packet. Another option for VPP is to maintain a packet context
Re: [lng-odp] APIs for dealing with compact handles
Thanks Bill for initiating the thread. Please checkout some more details*(**i**nline)* on the requirements & proposal. On 5/17/2017 8:50 PM, Bill Fischofer wrote: This thread is to discuss ideas and proposed solutions to two issues that have been raised by Sachin relating to VPP needs, as well as Honnappa relating to the scalable scheduler. Background = ODP handles are abstract types that implementations may define to be of arbitrary bit width in size. However, for a number of reasons (e.g., provision of strong typing support, ABI compatibility, efficiency of internal manipulation, etc.) these are typically represented as 64-bit quantities. Some applications that store handles in their own structures wish to minimize the cache footprint consumed by these structures and so would like an option to store handles in a more compact format that uses a smaller number of bits. To date 32-bits seems sufficient for application need, however in theory 16 or even 8 bits might be desirable in some circumstances. We already have an example of 8-bit handles in the odp_packet_seg_t type, where odp-linux uses an 8-bit representation of this type as a segment index when ODP is configured with --enable-abi-compat=no while using a 64-bit size when configured with --enable-abi-compat=yes. Considerations In choosing the bit width to use in representing handles there are two main considerations that implementations must take into account. First, to achieve strong typing in C, handles need to be of pointer width. For development this is a very valuable feature, which is why implementations are encouraged to provide strong typing for ODP abstract types. Second, for ABI compatibility it is required that all implementations use the same width for types that are to be ABI compatible across different implementations. Implementations may interpret the bits of a handle very differently, but all must agree that handles are of the same bit width if they wish to be binary compatible with each other. Stated Needs === VPP currently packages its metadata into a vlib_mbuf struct that is used pervasively to reference packets that are being processed by VPP nodes. The address of this struct is desired to be held in compressed (32-bit) format. Today the vlib_mbuf is implemented as a user area associated with an odp_packet_t. As such the odp_packet_user_area() API returns a (64-bit) pointer. What is desired is a compact representation of this address. VPP collects bunch of packets from ODP/DPDK input node and looks for inline "struct vlib_buffer" address in each packet. Then it creates a VPP Library Frame which is a collection of the vlib_buffers (vectors). For this, VPP converts 64-bit address of each vlib_buffer to a 32-bit index and save in the VLib frame and pass this frame to next Node. In each processing node in Data path where packet contents are accessed, VPP converts this 32-bit index to actual 64-bit address to get packet data pointer. In current implementation, VPP converts 32-bit index to address @ ~900 places in overall code via API: vlib_get_buffer (vlib_main_t * vm, u32 buffer_index) *Code reference*: GIT: https://git.fd.io/odp4vpp/log/ Files: vlib/vlib/buffer_funcs.h vlib/vlib/buffer.h VPP on the transmit side also needs to obtain the odp_packet_t associated with a vlib_mbuf. For the scalable scheduler, the desire is for a compact representation of an odp_event_t that can be stored in a space-efficient manner in queues. Proposed Solutions === Outlined here are a couple of proposed solutions to these problems. Please feel free to propose alternate solutions as well. For the case of the compact user area pointers needed by VPP, the suggestion has been made that ODP pools provide an API to return pool bounds information so that VPP can convert the user area pointers to a more compact index. However, this makes a number of assumptions about the internals of ODP pools that may or may not be portable or practical in all implementations. Since the requirement is for a compact representation of the user area address, a more direct solution may be simply to provide a set of new APIs that address this need directly: uint32_t odp_packet_user_area_index(odp_packet_t pkt); This API would return a 32-bit index of the user area associated with an odp_packet_t. Note that since user areas are mapped one-to-one with ODP packets, this can serve effectively as a packet index as well. With this API, applications can obtain the user area address directly or an indirectly in a compact form. The problem is converting the index back into the user area address. An API of the form: void *odp_packet_user_area_addr(uint32_t ndx); Assumes that this is a reversible mapping, which probably isn't true. However, adding the odp_packet_t as a second argument would be pointless since if the application has the odp_packet_t it can
Re: [lng-odp] [PATCH] test: generator: replace gettimeofday() with ODP API calls
O, yes, I see, it is the same entity to process both ICMP request/reply and can piggyback opaque payload, sorry for the misunderstanding, this still applied to the master branch and: Reviewed-and-tested-by: Yi He On 24 May 2017 at 16:12, Bogdan Pricope wrote: > Hi Yi, > > As I said in my reply, the sender is also the interpreter of the data. > The peer must only send the payload unmodified in echo reply - it is > not relevant if it understands or not the payload (it is opaque data > for peer): you can ping la Ubuntu or FreeBSD machine... don't expect > them to understand the payload but only to send it back unmodified. > > Best regards, > Bogdan > > On 24 May 2017 at 11:03, Yi He wrote: > > O, sorry Bogdan missed your reply, > > > > I saw the time value in ICMP message was filled(sending) by > "memcpy(tval_d, > > ..., sizeof(uint64_t));" and processed(receiving) as "memcpy(&tsend, ..., > > sizeof(uint64_t));" > > > > If the sending peer is little endian and the receiving peer is big > endian I > > think it will cause wrong interpretation, right? > > > > Best Regards, Yi > > > > On 24 May 2017 at 15:48, Bogdan Pricope > wrote: > >> > >> Ping. > >> > >> On 3 May 2017 at 11:45, Bogdan Pricope > wrote: > >> > Hi Yi, > >> > > >> > I disagree: bytes sent in Data field of Echo request are opaque and > >> > have no meaning for any other entity then ‘me’ (the sender of echo > >> > request / receiver of echo reply). > >> > > >> > The only obligation of the receiver of echo request, as stated by RFC > >> > 792 is: > >> > “The data received in the echo message must be returned in the echo > >> > reply message.” > >> > > >> > There is no standardization on what should be there (some even using > >> > it to convey commands/data – see „Loki ICMP Tunneling”) so it can be > >> > whatever sender wants –endianness transformations are not useful in > >> > this case. > >> > > >> > BR, > >> > Bogdan > >> > > >> > On 19 April 2017 at 06:08, Yi He wrote: > >> >> Hi, Bogdan > >> >> > >> >> Consider endianness for this uint64_t time value carried in ICMP > >> >> packets, > >> >> need htonl and ntohl here. > >> >> > >> >> Best Regards, Yi > >> >> > >> >> > >> >> > >> >> On 11 April 2017 at 19:31, Bogdan Pricope > > >> >> wrote: > >> >>> > >> >>> Ping! > >> >>> > >> >>> > >> >>> On 3 April 2017 at 13:00, Bogdan Pricope > > >> >>> wrote: > >> >>> > Signed-off-by: Bogdan Pricope > >> >>> > --- > >> >>> > example/generator/odp_generator.c | 89 > >> >>> > ++- > >> >>> > 1 file changed, 41 insertions(+), 48 deletions(-) > >> >>> > > >> >>> > diff --git a/example/generator/odp_generator.c > >> >>> > b/example/generator/odp_generator.c > >> >>> > index 95fb543..9c49d94 100644 > >> >>> > --- a/example/generator/odp_generator.c > >> >>> > +++ b/example/generator/odp_generator.c > >> >>> > @@ -119,7 +119,6 @@ static void parse_args(int argc, char *argv[], > >> >>> > appl_args_t *appl_args); > >> >>> > static void print_info(char *progname, appl_args_t *appl_args); > >> >>> > static void usage(char *progname); > >> >>> > static int scan_ip(char *buf, unsigned int *paddr); > >> >>> > -static void tv_sub(struct timeval *recvtime, struct timeval > >> >>> > *sendtime); > >> >>> > static void print_global_stats(int num_workers); > >> >>> > > >> >>> > /** > >> >>> > @@ -348,7 +347,7 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t > >> >>> > pool, > >> >>> > odp_packet_t pkt_ref) > >> >>> > char *buf; > >> >>> > odph_ipv4hdr_t *ip; > >> >>> > odph_icmphdr_t *icmp; > >> >>> > - struct timeval tval; > >> >>> > + uint64_t tval; > >> >>> > uint8_t *tval_d; > >> >>> > unsigned short seq; > >> >>> > > >> >>> > @@ -372,12 +371,12 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t > >> >>> > pool, > >> >>> > odp_packet_t pkt_ref) > >> >>> > /* icmp */ > >> >>> > icmp = (odph_icmphdr_t *)(buf + ODPH_ETHHDR_LEN + > >> >>> > ODPH_IPV4HDR_LEN); > >> >>> > icmp->un.echo.sequence = ip->id; > >> >>> > + > >> >>> > tval_d = (uint8_t *)(buf + ODPH_ETHHDR_LEN + > >> >>> > ODPH_IPV4HDR_LEN + > >> >>> > ODPH_ICMPHDR_LEN); > >> >>> > - /* TODO This should be changed to use an > >> >>> > -* ODP timer API once one exists. */ > >> >>> > - gettimeofday(&tval, NULL); > >> >>> > - memcpy(tval_d, &tval, sizeof(struct timeval)); > >> >>> > + tval = odp_time_to_ns(odp_time_local()); > >> >>> > + memcpy(tval_d, &tval, sizeof(uint64_t)); > >> >>> > + > >> >>> > icmp->chksum = 0; > >> >>> > icmp->chksum = odph_chksum(icmp, args->appl.payload + > >> >>> > ODPH_ICMPHDR_LEN); > >> >>> > > >> >>> > @@ -594,6 +593,40 @@ static int gen_send_thread(void *arg) > >> >>> > } > >> >>> > > >> >>> > /** > >> >>> > + * Process icmp packets > >> >>> > + * > >> >>> > + * @param icmp icmp header address > >> >>> > + * @param msg output buffer > >> >>> > + */ > >> >>> > + >
Re: [lng-odp] [RFCv4] dpdk: enable hardware checksum support
Hi Matias,
Using ptypes reported by dpdk in parser was intended for another patch
(next work after csum).
I guess your test is a degradation test (due to new ifs) and you did
not enabled csum offloads/ set flags on packets.
What will be interesting to see:
- in a generation or termination test (UDP), what will be
degradation/gain with csum offload enabled
- how degradation/gain is changing with bigger packets (256 bytes vs 64 bytes)
BR,
Bogdan
On 24 May 2017 at 10:53, Elo, Matias (Nokia - FI/Espoo)
wrote:
> Hi Bogdan,
>
> I ran a quick test run with the patch and the overhead seems to be
> surprisingly small at least on a Xeon cpu (E5-2697v3). However, I would
> still suggest making some changes to the code. More below.
>
> -Matias
>
>
>
>>
>> @@ -605,9 +663,11 @@ static inline int mbuf_to_pkt(pktio_entry_t
>> *pktio_entry,
>>int nb_pkts = 0;
>>int alloc_len, num;
>>odp_pool_t pool = pktio_entry->s.pkt_dpdk.pool;
>> + odp_pktin_config_opt_t *pktin_cfg;
>>
>>/* Allocate maximum sized packets */
>>alloc_len = pktio_entry->s.pkt_dpdk.data_room;
>> + pktin_cfg = &pktio_entry->s.config.pktin;
>>
>>num = packet_alloc_multi(pool, alloc_len, pkt_table, mbuf_num);
>>if (num != mbuf_num) {
>> @@ -658,6 +718,34 @@ static inline int mbuf_to_pkt(pktio_entry_t
>> *pktio_entry,
>>if (mbuf->ol_flags & PKT_RX_RSS_HASH)
>>odp_packet_flow_hash_set(pkt, mbuf->hash.rss);
>>
>> + if ((mbuf->packet_type & RTE_PTYPE_L3_MASK) ==
>> RTE_PTYPE_L3_IPV4 &&
>> + pktin_cfg->bit.ipv4_chksum &&
>> + mbuf->ol_flags & PKT_RX_IP_CKSUM_BAD) {
>> + if (pktin_cfg->bit.drop_ipv4_err) {
>> + odp_packet_free(pkt);
>> + continue;
>> + } else
>> + pkt_hdr->p.error_flags.ip_err = 1;
>> + }
>> +
>> + if ((mbuf->packet_type & RTE_PTYPE_L4_MASK) ==
>> RTE_PTYPE_L4_UDP &&
>> + pktin_cfg->bit.udp_chksum &&
>> + mbuf->ol_flags & PKT_RX_L4_CKSUM_BAD) {
>> + if (pktin_cfg->bit.drop_udp_err) {
>> + odp_packet_free(pkt);
>> + continue;
>> + } else
>> + pkt_hdr->p.error_flags.udp_err = 1;
>> + } else if ((mbuf->packet_type & RTE_PTYPE_L4_MASK) ==
>> RTE_PTYPE_L4_TCP &&
>> + pktin_cfg->bit.tcp_chksum &&
>> + mbuf->ol_flags & PKT_RX_L4_CKSUM_BAD) {
>> + if (pktin_cfg->bit.drop_tcp_err) {
>> + odp_packet_free(pkt);
>> + continue;
>> + } else
>> + pkt_hdr->p.error_flags.tcp_err = 1;
>> + }
>> +
>
> Instead of doing packet parsing and checksum validation separately I would
> do both in one function. The api-next pktio code (should be merged to
> master) has a new configuration option 'odp_pktio_config_t.parser.layer',
> which selects the parsing level. packet_parse_layer() function is then used
> to parse the received packet up to the selected level.
>
> So, instead of of calling packet_parse_layer() in dpdk pktio I would add a
> new dpdk specific implementation of this function. This way we can exploit
> all dpdk packet parsing features in addition to the checksum calculations.
> Also, by doing this you can remove most of the if() calls above. Enabling a
> higher protocol layer checksum calculation than the selected parsing level
> would be a user error (e.g. ODP_PKTIO_PARSER_LAYER_L2 and TCP checksum
> enabled).
>
>
Re: [lng-odp] [PATCH] test: generator: replace gettimeofday() with ODP API calls
Hi Yi,
As I said in my reply, the sender is also the interpreter of the data.
The peer must only send the payload unmodified in echo reply - it is
not relevant if it understands or not the payload (it is opaque data
for peer): you can ping la Ubuntu or FreeBSD machine... don't expect
them to understand the payload but only to send it back unmodified.
Best regards,
Bogdan
On 24 May 2017 at 11:03, Yi He wrote:
> O, sorry Bogdan missed your reply,
>
> I saw the time value in ICMP message was filled(sending) by "memcpy(tval_d,
> ..., sizeof(uint64_t));" and processed(receiving) as "memcpy(&tsend, ...,
> sizeof(uint64_t));"
>
> If the sending peer is little endian and the receiving peer is big endian I
> think it will cause wrong interpretation, right?
>
> Best Regards, Yi
>
> On 24 May 2017 at 15:48, Bogdan Pricope wrote:
>>
>> Ping.
>>
>> On 3 May 2017 at 11:45, Bogdan Pricope wrote:
>> > Hi Yi,
>> >
>> > I disagree: bytes sent in Data field of Echo request are opaque and
>> > have no meaning for any other entity then ‘me’ (the sender of echo
>> > request / receiver of echo reply).
>> >
>> > The only obligation of the receiver of echo request, as stated by RFC
>> > 792 is:
>> > “The data received in the echo message must be returned in the echo
>> > reply message.”
>> >
>> > There is no standardization on what should be there (some even using
>> > it to convey commands/data – see „Loki ICMP Tunneling”) so it can be
>> > whatever sender wants –endianness transformations are not useful in
>> > this case.
>> >
>> > BR,
>> > Bogdan
>> >
>> > On 19 April 2017 at 06:08, Yi He wrote:
>> >> Hi, Bogdan
>> >>
>> >> Consider endianness for this uint64_t time value carried in ICMP
>> >> packets,
>> >> need htonl and ntohl here.
>> >>
>> >> Best Regards, Yi
>> >>
>> >>
>> >>
>> >> On 11 April 2017 at 19:31, Bogdan Pricope
>> >> wrote:
>> >>>
>> >>> Ping!
>> >>>
>> >>>
>> >>> On 3 April 2017 at 13:00, Bogdan Pricope
>> >>> wrote:
>> >>> > Signed-off-by: Bogdan Pricope
>> >>> > ---
>> >>> > example/generator/odp_generator.c | 89
>> >>> > ++-
>> >>> > 1 file changed, 41 insertions(+), 48 deletions(-)
>> >>> >
>> >>> > diff --git a/example/generator/odp_generator.c
>> >>> > b/example/generator/odp_generator.c
>> >>> > index 95fb543..9c49d94 100644
>> >>> > --- a/example/generator/odp_generator.c
>> >>> > +++ b/example/generator/odp_generator.c
>> >>> > @@ -119,7 +119,6 @@ static void parse_args(int argc, char *argv[],
>> >>> > appl_args_t *appl_args);
>> >>> > static void print_info(char *progname, appl_args_t *appl_args);
>> >>> > static void usage(char *progname);
>> >>> > static int scan_ip(char *buf, unsigned int *paddr);
>> >>> > -static void tv_sub(struct timeval *recvtime, struct timeval
>> >>> > *sendtime);
>> >>> > static void print_global_stats(int num_workers);
>> >>> >
>> >>> > /**
>> >>> > @@ -348,7 +347,7 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t
>> >>> > pool,
>> >>> > odp_packet_t pkt_ref)
>> >>> > char *buf;
>> >>> > odph_ipv4hdr_t *ip;
>> >>> > odph_icmphdr_t *icmp;
>> >>> > - struct timeval tval;
>> >>> > + uint64_t tval;
>> >>> > uint8_t *tval_d;
>> >>> > unsigned short seq;
>> >>> >
>> >>> > @@ -372,12 +371,12 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t
>> >>> > pool,
>> >>> > odp_packet_t pkt_ref)
>> >>> > /* icmp */
>> >>> > icmp = (odph_icmphdr_t *)(buf + ODPH_ETHHDR_LEN +
>> >>> > ODPH_IPV4HDR_LEN);
>> >>> > icmp->un.echo.sequence = ip->id;
>> >>> > +
>> >>> > tval_d = (uint8_t *)(buf + ODPH_ETHHDR_LEN +
>> >>> > ODPH_IPV4HDR_LEN +
>> >>> > ODPH_ICMPHDR_LEN);
>> >>> > - /* TODO This should be changed to use an
>> >>> > -* ODP timer API once one exists. */
>> >>> > - gettimeofday(&tval, NULL);
>> >>> > - memcpy(tval_d, &tval, sizeof(struct timeval));
>> >>> > + tval = odp_time_to_ns(odp_time_local());
>> >>> > + memcpy(tval_d, &tval, sizeof(uint64_t));
>> >>> > +
>> >>> > icmp->chksum = 0;
>> >>> > icmp->chksum = odph_chksum(icmp, args->appl.payload +
>> >>> > ODPH_ICMPHDR_LEN);
>> >>> >
>> >>> > @@ -594,6 +593,40 @@ static int gen_send_thread(void *arg)
>> >>> > }
>> >>> >
>> >>> > /**
>> >>> > + * Process icmp packets
>> >>> > + *
>> >>> > + * @param icmp icmp header address
>> >>> > + * @param msg output buffer
>> >>> > + */
>> >>> > +
>> >>> > +static void process_icmp_pkt(odph_icmphdr_t *icmp, char *msg)
>> >>> > +{
>> >>> > + uint64_t trecv;
>> >>> > + uint64_t tsend;
>> >>> > + uint64_t rtt_ms, rtt_us;
>> >>> > +
>> >>> > + msg[0] = 0;
>> >>> > +
>> >>> > + if (icmp->type == ICMP_ECHOREPLY) {
>> >>> > + odp_atomic_inc_u64(&counters.icmp);
>> >>> > +
>> >>> > + memcpy(&tsend, (uint8_t *)icmp + ODPH_ICMPHDR_LEN,
>> >>> > + sizeof(uint64_t));
>> >>> > + trecv = odp_time_t
Re: [lng-odp] [PATCH] test: generator: replace gettimeofday() with ODP API calls
O, sorry Bogdan missed your reply,
I saw the time value in ICMP message was filled(sending) by "memcpy(tval_d,
..., sizeof(uint64_t));" and processed(receiving) as "memcpy(&tsend, ...,
sizeof(uint64_t));"
If the sending peer is little endian and the receiving peer is big endian I
think it will cause wrong interpretation, right?
Best Regards, Yi
On 24 May 2017 at 15:48, Bogdan Pricope wrote:
> Ping.
>
> On 3 May 2017 at 11:45, Bogdan Pricope wrote:
> > Hi Yi,
> >
> > I disagree: bytes sent in Data field of Echo request are opaque and
> > have no meaning for any other entity then ‘me’ (the sender of echo
> > request / receiver of echo reply).
> >
> > The only obligation of the receiver of echo request, as stated by RFC
> 792 is:
> > “The data received in the echo message must be returned in the echo
> > reply message.”
> >
> > There is no standardization on what should be there (some even using
> > it to convey commands/data – see „Loki ICMP Tunneling”) so it can be
> > whatever sender wants –endianness transformations are not useful in
> > this case.
> >
> > BR,
> > Bogdan
> >
> > On 19 April 2017 at 06:08, Yi He wrote:
> >> Hi, Bogdan
> >>
> >> Consider endianness for this uint64_t time value carried in ICMP
> packets,
> >> need htonl and ntohl here.
> >>
> >> Best Regards, Yi
> >>
> >>
> >>
> >> On 11 April 2017 at 19:31, Bogdan Pricope
> wrote:
> >>>
> >>> Ping!
> >>>
> >>>
> >>> On 3 April 2017 at 13:00, Bogdan Pricope
> >>> wrote:
> >>> > Signed-off-by: Bogdan Pricope
> >>> > ---
> >>> > example/generator/odp_generator.c | 89
> >>> > ++-
> >>> > 1 file changed, 41 insertions(+), 48 deletions(-)
> >>> >
> >>> > diff --git a/example/generator/odp_generator.c
> >>> > b/example/generator/odp_generator.c
> >>> > index 95fb543..9c49d94 100644
> >>> > --- a/example/generator/odp_generator.c
> >>> > +++ b/example/generator/odp_generator.c
> >>> > @@ -119,7 +119,6 @@ static void parse_args(int argc, char *argv[],
> >>> > appl_args_t *appl_args);
> >>> > static void print_info(char *progname, appl_args_t *appl_args);
> >>> > static void usage(char *progname);
> >>> > static int scan_ip(char *buf, unsigned int *paddr);
> >>> > -static void tv_sub(struct timeval *recvtime, struct timeval
> *sendtime);
> >>> > static void print_global_stats(int num_workers);
> >>> >
> >>> > /**
> >>> > @@ -348,7 +347,7 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t
> pool,
> >>> > odp_packet_t pkt_ref)
> >>> > char *buf;
> >>> > odph_ipv4hdr_t *ip;
> >>> > odph_icmphdr_t *icmp;
> >>> > - struct timeval tval;
> >>> > + uint64_t tval;
> >>> > uint8_t *tval_d;
> >>> > unsigned short seq;
> >>> >
> >>> > @@ -372,12 +371,12 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t
> pool,
> >>> > odp_packet_t pkt_ref)
> >>> > /* icmp */
> >>> > icmp = (odph_icmphdr_t *)(buf + ODPH_ETHHDR_LEN +
> >>> > ODPH_IPV4HDR_LEN);
> >>> > icmp->un.echo.sequence = ip->id;
> >>> > +
> >>> > tval_d = (uint8_t *)(buf + ODPH_ETHHDR_LEN +
> ODPH_IPV4HDR_LEN +
> >>> > ODPH_ICMPHDR_LEN);
> >>> > - /* TODO This should be changed to use an
> >>> > -* ODP timer API once one exists. */
> >>> > - gettimeofday(&tval, NULL);
> >>> > - memcpy(tval_d, &tval, sizeof(struct timeval));
> >>> > + tval = odp_time_to_ns(odp_time_local());
> >>> > + memcpy(tval_d, &tval, sizeof(uint64_t));
> >>> > +
> >>> > icmp->chksum = 0;
> >>> > icmp->chksum = odph_chksum(icmp, args->appl.payload +
> >>> > ODPH_ICMPHDR_LEN);
> >>> >
> >>> > @@ -594,6 +593,40 @@ static int gen_send_thread(void *arg)
> >>> > }
> >>> >
> >>> > /**
> >>> > + * Process icmp packets
> >>> > + *
> >>> > + * @param icmp icmp header address
> >>> > + * @param msg output buffer
> >>> > + */
> >>> > +
> >>> > +static void process_icmp_pkt(odph_icmphdr_t *icmp, char *msg)
> >>> > +{
> >>> > + uint64_t trecv;
> >>> > + uint64_t tsend;
> >>> > + uint64_t rtt_ms, rtt_us;
> >>> > +
> >>> > + msg[0] = 0;
> >>> > +
> >>> > + if (icmp->type == ICMP_ECHOREPLY) {
> >>> > + odp_atomic_inc_u64(&counters.icmp);
> >>> > +
> >>> > + memcpy(&tsend, (uint8_t *)icmp + ODPH_ICMPHDR_LEN,
> >>> > + sizeof(uint64_t));
> >>> > + trecv = odp_time_to_ns(odp_time_local());
> >>> > + rtt_ms = (trecv - tsend) / ODP_TIME_MSEC_IN_NS;
> >>> > + rtt_us = (trecv - tsend) / ODP_TIME_USEC_IN_NS -
> >>> > + 1000 * rtt_ms;
> >>> > + sprintf(msg,
> >>> > + "ICMP Echo Reply seq %d time %"
> >>> > + PRIu64 ".%.03" PRIu64" ms",
> >>> > + odp_be_to_cpu_16(icmp->un.echo.sequence),
> >>> > + rtt_ms, rtt_us);
> >>> > + } else if (icmp->type == ICMP_ECHO) {
> >>> > + sp
Re: [lng-odp] [API-NEXT PATCH v6 1/6] test: odp_sched_latency: misc improvements
> -Original Message- > From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@linaro.org] > Sent: Wednesday, May 24, 2017 6:56 AM > To: Savolainen, Petri (Nokia - FI/Espoo) > Cc: Brian Brooks ; lng-odp@lists.linaro.org; Ola > Liljedahl > Subject: Re: [lng-odp] [API-NEXT PATCH v6 1/6] test: odp_sched_latency: > misc improvements > > On 23 May 2017 at 01:52, Savolainen, Petri (Nokia - FI/Espoo) > wrote: > > > > > >> -Original Message- > >> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of > Brian > >> Brooks > >> Sent: Tuesday, May 23, 2017 1:28 AM > >> To: lng-odp@lists.linaro.org > >> Cc: Ola Liljedahl > >> Subject: [lng-odp] [API-NEXT PATCH v6 1/6] test: odp_sched_latency: > misc > >> improvements > >> > >> Increase TEST_ROUNDS for all schedulers except SP for more > deterministic > >> test results. SP is too slow to handle the increased running time. > >> > >> Use an explicit scheduling group to inform the scheduler of the threads > >> that will join the group. > >> > >> Add a timeout to the schedule call for draining queues. > >> > >> Signed-off-by: Brian Brooks > >> Signed-off-by: Ola Liljedahl > >> --- > >> test/common_plat/performance/odp_sched_latency.c | 62 > >> > >> 1 file changed, 62 insertions(+) > >> > >> diff --git a/test/common_plat/performance/odp_sched_latency.c > >> b/test/common_plat/performance/odp_sched_latency.c > >> index 026f2f6c..3fd969ca 100644 > >> --- a/test/common_plat/performance/odp_sched_latency.c > >> +++ b/test/common_plat/performance/odp_sched_latency.c > >> @@ -28,7 +28,13 @@ > >> #define MAX_WORKERS64/**< Maximum number of worker > >> threads */ > >> #define MAX_QUEUES 4096 /**< Maximum number of queues > >> */ > >> #define EVENT_POOL_SIZE(1024 * 1024) /**< Event pool size */ > >> + > >> +#ifdef ODP_SCHEDULE_SP > >> #define TEST_ROUNDS (4 * 1024 * 1024)/**< Test rounds for each > >> thread */ > >> +#else > >> +#define TEST_ROUNDS (32 * 1024 * 1024) /**< Test rounds for each > >> thread */ > >> +#endif > > > > > > Cannot do this. ODP_SCHEDULE_SP is not an ODP API definition - it cannot > be used in an application. Applications must be written against the API > spec. This code would not even build on any other implementation than odp- > linux (and maybe odp-dpdk which copies lots of odp-linux code). > > > > This is a test case. We want to run for more iterations. > Unfortunately, running SP scheduler for more number of iterations > causes the test case to take a lot of time. > It's an ODP application. No matter which is the purpose of the application, it must use ODP API correctly. All our applications are examples of how to use ODP API, and we do not want to give bad examples. > Why this code would not build on other implementation. If > ODP_SCHEDULE_SP is not defined, then TEST_ROUNDS would get defined to > higher number of iterations. I was apparently thinking of #if ODP_SCHEDULE_SP. Anyway, this definition is not part of API and thus must not be used by any application. -Petri
Re: [lng-odp] [RFCv4] dpdk: enable hardware checksum support
Hi Bogdan,
I ran a quick test run with the patch and the overhead seems to be surprisingly
small at least on a Xeon cpu (E5-2697v3). However, I would still suggest making
some changes to the code. More below.
-Matias
>
> @@ -605,9 +663,11 @@ static inline int mbuf_to_pkt(pktio_entry_t *pktio_entry,
>int nb_pkts = 0;
>int alloc_len, num;
>odp_pool_t pool = pktio_entry->s.pkt_dpdk.pool;
> + odp_pktin_config_opt_t *pktin_cfg;
>
>/* Allocate maximum sized packets */
>alloc_len = pktio_entry->s.pkt_dpdk.data_room;
> + pktin_cfg = &pktio_entry->s.config.pktin;
>
>num = packet_alloc_multi(pool, alloc_len, pkt_table, mbuf_num);
>if (num != mbuf_num) {
> @@ -658,6 +718,34 @@ static inline int mbuf_to_pkt(pktio_entry_t *pktio_entry,
>if (mbuf->ol_flags & PKT_RX_RSS_HASH)
>odp_packet_flow_hash_set(pkt, mbuf->hash.rss);
>
> + if ((mbuf->packet_type & RTE_PTYPE_L3_MASK) ==
> RTE_PTYPE_L3_IPV4 &&
> + pktin_cfg->bit.ipv4_chksum &&
> + mbuf->ol_flags & PKT_RX_IP_CKSUM_BAD) {
> + if (pktin_cfg->bit.drop_ipv4_err) {
> + odp_packet_free(pkt);
> + continue;
> + } else
> + pkt_hdr->p.error_flags.ip_err = 1;
> + }
> +
> + if ((mbuf->packet_type & RTE_PTYPE_L4_MASK) == RTE_PTYPE_L4_UDP
> &&
> + pktin_cfg->bit.udp_chksum &&
> + mbuf->ol_flags & PKT_RX_L4_CKSUM_BAD) {
> + if (pktin_cfg->bit.drop_udp_err) {
> + odp_packet_free(pkt);
> + continue;
> + } else
> + pkt_hdr->p.error_flags.udp_err = 1;
> + } else if ((mbuf->packet_type & RTE_PTYPE_L4_MASK) ==
> RTE_PTYPE_L4_TCP &&
> + pktin_cfg->bit.tcp_chksum &&
> + mbuf->ol_flags & PKT_RX_L4_CKSUM_BAD) {
> + if (pktin_cfg->bit.drop_tcp_err) {
> + odp_packet_free(pkt);
> + continue;
> + } else
> + pkt_hdr->p.error_flags.tcp_err = 1;
> + }
> +
Instead of doing packet parsing and checksum validation separately I would do
both in one function. The api-next pktio code (should be merged to master) has
a new configuration option 'odp_pktio_config_t.parser.layer', which selects the
parsing level. packet_parse_layer() function is then used to parse the received
packet up to the selected level.
So, instead of of calling packet_parse_layer() in dpdk pktio I would add a new
dpdk specific implementation of this function. This way we can exploit all dpdk
packet parsing features in addition to the checksum calculations. Also, by
doing this you can remove most of the if() calls above. Enabling a higher
protocol layer checksum calculation than the selected parsing level would be a
user error (e.g. ODP_PKTIO_PARSER_LAYER_L2 and TCP checksum enabled).
rfc-patch-bech.xlsx
Description: rfc-patch-bech.xlsx
Re: [lng-odp] [PATCH] test: generator: replace gettimeofday() with ODP API calls
Ping.
On 3 May 2017 at 11:45, Bogdan Pricope wrote:
> Hi Yi,
>
> I disagree: bytes sent in Data field of Echo request are opaque and
> have no meaning for any other entity then ‘me’ (the sender of echo
> request / receiver of echo reply).
>
> The only obligation of the receiver of echo request, as stated by RFC 792 is:
> “The data received in the echo message must be returned in the echo
> reply message.”
>
> There is no standardization on what should be there (some even using
> it to convey commands/data – see „Loki ICMP Tunneling”) so it can be
> whatever sender wants –endianness transformations are not useful in
> this case.
>
> BR,
> Bogdan
>
> On 19 April 2017 at 06:08, Yi He wrote:
>> Hi, Bogdan
>>
>> Consider endianness for this uint64_t time value carried in ICMP packets,
>> need htonl and ntohl here.
>>
>> Best Regards, Yi
>>
>>
>>
>> On 11 April 2017 at 19:31, Bogdan Pricope wrote:
>>>
>>> Ping!
>>>
>>>
>>> On 3 April 2017 at 13:00, Bogdan Pricope
>>> wrote:
>>> > Signed-off-by: Bogdan Pricope
>>> > ---
>>> > example/generator/odp_generator.c | 89
>>> > ++-
>>> > 1 file changed, 41 insertions(+), 48 deletions(-)
>>> >
>>> > diff --git a/example/generator/odp_generator.c
>>> > b/example/generator/odp_generator.c
>>> > index 95fb543..9c49d94 100644
>>> > --- a/example/generator/odp_generator.c
>>> > +++ b/example/generator/odp_generator.c
>>> > @@ -119,7 +119,6 @@ static void parse_args(int argc, char *argv[],
>>> > appl_args_t *appl_args);
>>> > static void print_info(char *progname, appl_args_t *appl_args);
>>> > static void usage(char *progname);
>>> > static int scan_ip(char *buf, unsigned int *paddr);
>>> > -static void tv_sub(struct timeval *recvtime, struct timeval *sendtime);
>>> > static void print_global_stats(int num_workers);
>>> >
>>> > /**
>>> > @@ -348,7 +347,7 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t pool,
>>> > odp_packet_t pkt_ref)
>>> > char *buf;
>>> > odph_ipv4hdr_t *ip;
>>> > odph_icmphdr_t *icmp;
>>> > - struct timeval tval;
>>> > + uint64_t tval;
>>> > uint8_t *tval_d;
>>> > unsigned short seq;
>>> >
>>> > @@ -372,12 +371,12 @@ static odp_packet_t pack_icmp_pkt(odp_pool_t pool,
>>> > odp_packet_t pkt_ref)
>>> > /* icmp */
>>> > icmp = (odph_icmphdr_t *)(buf + ODPH_ETHHDR_LEN +
>>> > ODPH_IPV4HDR_LEN);
>>> > icmp->un.echo.sequence = ip->id;
>>> > +
>>> > tval_d = (uint8_t *)(buf + ODPH_ETHHDR_LEN + ODPH_IPV4HDR_LEN +
>>> > ODPH_ICMPHDR_LEN);
>>> > - /* TODO This should be changed to use an
>>> > -* ODP timer API once one exists. */
>>> > - gettimeofday(&tval, NULL);
>>> > - memcpy(tval_d, &tval, sizeof(struct timeval));
>>> > + tval = odp_time_to_ns(odp_time_local());
>>> > + memcpy(tval_d, &tval, sizeof(uint64_t));
>>> > +
>>> > icmp->chksum = 0;
>>> > icmp->chksum = odph_chksum(icmp, args->appl.payload +
>>> > ODPH_ICMPHDR_LEN);
>>> >
>>> > @@ -594,6 +593,40 @@ static int gen_send_thread(void *arg)
>>> > }
>>> >
>>> > /**
>>> > + * Process icmp packets
>>> > + *
>>> > + * @param icmp icmp header address
>>> > + * @param msg output buffer
>>> > + */
>>> > +
>>> > +static void process_icmp_pkt(odph_icmphdr_t *icmp, char *msg)
>>> > +{
>>> > + uint64_t trecv;
>>> > + uint64_t tsend;
>>> > + uint64_t rtt_ms, rtt_us;
>>> > +
>>> > + msg[0] = 0;
>>> > +
>>> > + if (icmp->type == ICMP_ECHOREPLY) {
>>> > + odp_atomic_inc_u64(&counters.icmp);
>>> > +
>>> > + memcpy(&tsend, (uint8_t *)icmp + ODPH_ICMPHDR_LEN,
>>> > + sizeof(uint64_t));
>>> > + trecv = odp_time_to_ns(odp_time_local());
>>> > + rtt_ms = (trecv - tsend) / ODP_TIME_MSEC_IN_NS;
>>> > + rtt_us = (trecv - tsend) / ODP_TIME_USEC_IN_NS -
>>> > + 1000 * rtt_ms;
>>> > + sprintf(msg,
>>> > + "ICMP Echo Reply seq %d time %"
>>> > + PRIu64 ".%.03" PRIu64" ms",
>>> > + odp_be_to_cpu_16(icmp->un.echo.sequence),
>>> > + rtt_ms, rtt_us);
>>> > + } else if (icmp->type == ICMP_ECHO) {
>>> > + sprintf(msg, "Icmp Echo Request");
>>> > + }
>>> > +}
>>> > +
>>> > +/**
>>> > * Print odp packets
>>> > *
>>> > * @param thr worker id
>>> > @@ -606,16 +639,12 @@ static void print_pkts(int thr, odp_packet_t
>>> > pkt_tbl[], unsigned len)
>>> > char *buf;
>>> > odph_ipv4hdr_t *ip;
>>> > odph_icmphdr_t *icmp;
>>> > - struct timeval tvrecv;
>>> > - struct timeval tvsend;
>>> > - double rtt;
>>> > unsigned i;
>>> > size_t offset;
>>> > char msg[1024];
>>> > - int rlen;
>>> > +
>>> > for (i = 0; i < len; ++i) {
>>> > pkt = pkt_tbl[i];
>>> > -
Re: [lng-odp] Release needed
Ok, thanks for details. I will try to prepare release according to your list on this week. On 24 May 2017 at 10:38, Savolainen, Petri (Nokia - FI/Espoo) < petri.savolai...@nokia.com> wrote: > Hi, > > It's already two months since 1.14 release. We have again missed the > target of a release per month. Additionally, we have bunch of stuff in > api-next that could move to master, and thus to the next release. > > From api-next these API spec files (or parts) are OK to move into master: > * entire classification.h > * fix doxygen warnings > * entire crypto.h > * new deprecation support > * SHA1 and SHA512 enumerations > * odp_packet_data_range_t > * addition of auth_digest_len and AAD config > * entire hints.h > * new deprecation support > * partial packet.h > * addition of odp_packet_data_range_t > * keep in api-next: chksum_insert > * partial packet_io.h > * addition of parse config > * keep in api-next: ipsec config > * entire pool.h > * fix doxygen warnings > * entire queue.h > * addition of queue size capa / param > * entire support.h > * new file and type > * entire system_info.h > * added sys_info_print() > * entire time.h > * removed time_to_u64() > * entire tm.h > * fix doxygen warnings > > -Petri > > >
[lng-odp] Release needed
Hi, It's already two months since 1.14 release. We have again missed the target of a release per month. Additionally, we have bunch of stuff in api-next that could move to master, and thus to the next release. From api-next these API spec files (or parts) are OK to move into master: * entire classification.h * fix doxygen warnings * entire crypto.h * new deprecation support * SHA1 and SHA512 enumerations * odp_packet_data_range_t * addition of auth_digest_len and AAD config * entire hints.h * new deprecation support * partial packet.h * addition of odp_packet_data_range_t * keep in api-next: chksum_insert * partial packet_io.h * addition of parse config * keep in api-next: ipsec config * entire pool.h * fix doxygen warnings * entire queue.h * addition of queue size capa / param * entire support.h * new file and type * entire system_info.h * added sys_info_print() * entire time.h * removed time_to_u64() * entire tm.h * fix doxygen warnings -Petri
Re: [lng-odp] Summary of Expiration Discussion
This ‘status_queue’ looks fine to me. /Bogdan On 24 May 2017 at 02:20, Bill Fischofer wrote: > This is a quick summary of the expiration discussion held during > Monday's ARCH call. > > The current odp_ipsec_capability_t defines two fields: > > /** Soft expiry limit in seconds support > * > * 0: Limit is not supported > * 1: Limit is supported > */ > uint8_t soft_limit_sec; > > /** Hard expiry limit in seconds support > * > * 0: Limit is not supported > * 1: Limit is supported > */ > uint8_t hard_limit_sec; > > Presumably the uint8_t's here should be changed to odp_support_t's, or > removed entirely. On the odp_ipsec_sa_create() call passes an > odp_ipsec_param_t struct and one of the sub-structures in that is an > odp_ipsec_lifetime_t struct that specifies hard and soft expiry limits > for bytes, packets, and or time (in seconds). These lifetimes are > defined by RFC 4301 which states (Section 4.4.2.1): > > The following data items MUST be in the SAD: > ... > > - Lifetime of this SA: a time interval after which an SA must be > replaced with a new SA (and new SPI) or terminated, plus an > indication of which of these actions should occur. This may be > expressed as a time or byte count, or a simultaneous use of both > with the first lifetime to expire taking precedence. A compliant > implementation MUST support both types of lifetimes, and MUST > support a simultaneous use of both. >... > > Note: The details of how to handle the refreshing > of keys when SAs expire is a local matter. However, one > reasonable approach is: > > (a) If byte count is used, then the implementation SHOULD count the > number of bytes to which the IPsec cryptographic algorithm is > applied. For ESP, this is the encryption algorithm (including > Null encryption) and for AH, this is the authentication > algorithm. This includes pad bytes, etc. Note that > implementations MUST be able to handle having the counters at > the ends of an SA get out of synch, e.g., because of packet > loss or because the implementations at each end of the SA > aren't doing things the same way. > > (b) There SHOULD be two kinds of lifetime -- a soft lifetime that > warns the implementation to initiate action such as setting up > a replacement SA, and a hard lifetime when the current SA ends > and is destroyed. > > (c) If the entire packet does not get delivered during the SA's > lifetime, the packet SHOULD be discarded. > > With this background, it's clear that should we choose to remove > time-based expiration from the ODP IPsec API spec we would have an > incomplete IPsec specification that would require any ODP > implementation that wishes to be IPsec compliant to "fill in" the spec > on its own. That would not be good. Note also that the RFC says > nothing about counting packets, only bytes, so perhaps we shouldn't be > offering packet counts? > > Given that we want to keep these, the question is then how are they to > be handled? The argument I would make is that these are control > signals as they indicate that the control plane should begin rekeying > on an SA (soft expiration) or that an SA's lifetime has ended (hard > expiration). As such they should be odp_ipsec_status_t events, which > seems to be what IPsec users like OFP would prefer. > > Currently the odp_ipsec_param_t includes the fields: > > /** Destination queue for IPSEC events > * > * Operations in asynchronous or inline mode enqueue resulting events > * into this queue. > */ > odp_queue_t dest_queue; > > /** Classifier destination CoS for IPSEC result events > * > * Result events for successfully decapsulated packets are sent to > * classification through this CoS. Other result events are sent to > * 'dest_queue'. This field is considered only when 'pipeline' is > * ODP_IPSEC_PIPELINE_CLS. The CoS must not be shared between any pktio > * interface default CoS. > */ > odp_cos_t dest_cos; > > But perhaps this is too coarse. Having a dest_cos makes sense for > PIPELINE_CLS output but the current dest_queue is used for both > odp_ipsec_result_t and odp_ipsec_status_t events, which inherently > have different "consumers". So might it make more sense to split this > into: > > /** > * Output queue for IPSEC results > * > * Operations in asynchronous or inline mode enqueue result events are placed > * onto this queue. > */ > odp_queue_t result_queue; > > /** > * Output queue for IPSEC status > * > * Status events relating to this SA are placed onto this queue. > */ > odp_queue_t status_queue; > > This would also solve the "sync mode" problem that Dmitry mentioned. > An application that only intends to use IPsec lookaside operations and > then only in sync mode may set result_queue to ODP_QUEUE_INVALID. > However, if it wishes to specify a lifetime associated with this SA > then it MUST
