This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "".
The branch, api-next has been updated
via f6772a1c2c86c1982d68fc50480748751ac36e98 (commit)
via ea51e9f8dba20f06b56c3e293b5b1eebc01e3d71 (commit)
via 58a2fd9358675a54f2ed0f43ef3574a7b4a2c7dd (commit)
from 9fa4b3c5efa041351ba915ca35b3dfe252ecb34c (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit f6772a1c2c86c1982d68fc50480748751ac36e98
Author: Bill Fischofer <bill.fischofer(a)linaro.org>
Date: Mon Dec 12 09:06:17 2016 -0600
doc: userguide: expand crypto documentation to cover random apis
Clean up the crypto section of the User Guide and expand on the
ODP random data APIs.
Signed-off-by: Bill Fischofer <bill.fischofer(a)linaro.org>
Reviewed-by: Petri Savolainen <petri.savolainen(a)nokia.com>
Signed-off-by: Maxim Uvarov <maxim.uvarov(a)linaro.org>
diff --git a/doc/users-guide/users-guide-crypto.adoc b/doc/users-guide/users-guide-crypto.adoc
index 04b3e87..c18e369 100644
--- a/doc/users-guide/users-guide-crypto.adoc
+++ b/doc/users-guide/users-guide-crypto.adoc
@@ -1,7 +1,8 @@
== Cryptographic services
ODP provides APIs to perform cryptographic operations required by various
-communication protocols (e.g. IPSec). ODP cryptographic APIs are session based.
+communication protocols (_e.g.,_ IPsec). ODP cryptographic APIs are session
+based.
ODP provides APIs for following cryptographic services:
@@ -19,24 +20,26 @@ ODP supports synchronous and asynchronous crypto sessions. For asynchronous
sessions, the output of crypto operation is posted in a queue defined as
the completion queue in its session parameters.
-ODP crypto APIs support chained operation sessions in which hashing and ciphering
-both can be achieved using a single session and operation call. The order of
-cipher and hashing can be controlled by the `auth_cipher_text` session parameter.
+ODP crypto APIs support chained operation sessions in which hashing and
+ciphering both can be achieved using a single session and operation call. The
+order of cipher and hashing can be controlled by the `auth_cipher_text`
+session parameter.
Other Session parameters include algorithms, keys, initialization vector
-(optional), encode or decode, output queue for async mode and output packet pool
-for allocation of an output packet if required.
+(optional), encode or decode, output queue for async mode and output packet
+pool for allocation of an output packet if required.
=== Crypto operations
After session creation, a cryptographic operation can be applied to a packet
using the `odp_crypto_operation()` API. Applications may indicate a preference
-for synchronous or asynchronous processing in the session's `pref_mode` parameter.
-However crypto operations may complete synchronously even if an asynchronous
-preference is indicated, and applications must examine the `posted` output
-parameter from `odp_crypto_operation()` to determine whether the operation has
-completed or if an `ODP_EVENT_CRYPTO_COMPL` notification is expected. In the case
-of an async operation, the `posted` output parameter will be set to true.
+for synchronous or asynchronous processing in the session's `pref_mode`
+parameter. However crypto operations may complete synchronously even if an
+asynchronous preference is indicated, and applications must examine the
+`posted` output parameter from `odp_crypto_operation()` to determine whether
+the operation has completed or if an `ODP_EVENT_CRYPTO_COMPL` notification is
+expected. In the case of an async operation, the `posted` output parameter
+will be set to true.
The operation arguments specify for each packet the areas that are to be
@@ -49,9 +52,9 @@ In case of out-of-place mode output packet is different from input packet as
specified by the application, while in new buffer mode implementation allocates
a new output buffer from the session’s output pool.
-The application can also specify a context associated with a given operation that
-will be retained during async operation and can be retrieved via the completion
-event.
+The application can also specify a context associated with a given operation
+that will be retained during async operation and can be retrieved via the
+completion event.
Results of an asynchronous session will be posted as completion events to the
session’s completion queue, which can be accessed directly or via the ODP
@@ -60,12 +63,60 @@ result. The application has the responsibility to free the completion event.
=== Random number Generation
-ODP provides an API `odp_random_data()` to generate random data bytes. It has
-an argument to specify whether to use system entropy source for random number
-generation or not.
+ODP provides two APIs to generate various kinds of random data bytes. Random
+data is characterized by _kind_, which specifies the "quality" of the
+randomness required. ODP support three kinds of random data:
+
+ODP_RANDOM_BASIC:: No specific requirement other than the data appear to be
+uniformly distributed. Suitable for load-balancing or other non-cryptographic
+use.
+
+ODP_RANDOM_CRYPTO:: Data suitable for cryptographic use. This is a more
+stringent requirement that the data pass tests for statistical randomness.
+
+ODP_RANDOM_TRUE:: Data generated from a hardware entropy source rather than
+any software generated pseudo-random data. May not be available on all
+platforms.
+
+These form a hierarchy with BASIC being the lowest kind of random and TRUE
+behing the highest. The main API for accessing random data is:
+
+[source,c]
+-----
+int32_t odp_random_data(uint8_t buf, uint32_t len, odp_random_kind_t kind);
+-----
+
+The expectation is that lesser-quality random is easier and faster to generate
+while higher-quality random may take more time. Implementations are always free
+to substitute a higher kind of random than the one requested if they are able
+to do so more efficiently, however calls must return a failure indicator
+(rc < 0) if a higher kind of data is requested than the implementation can
+provide. This is most likely the case for ODP_RANDOM_TRUE since not all
+platforms have access to a true hardware random number generator.
+
+The `odp_random_max_kind()` API returns the highest kind of random data
+available on this implementation.
+
+For testing purposes it is often desirable to generate repeatable sequences
+of "random" data. To address this need ODP provides the additional API:
+
+[source,c]
+-----
+int32_t odp_random_test_data(uint8_t buf, uint32_t len, uint64_t *seed);
+-----
+
+This operates the same as `odp_random_data()` except that it always returns
+data of kind `ODP_RANDOM_BASIC` and an additional thread-local `seed`
+parameter is provide that specifies a seed value to use in generating the
+data. This value is updated on each call, so repeated calls with the same
+variable will generate a sequence of random data starting from the initial
+specified seed. If another sequence of calls is made starting with the same
+initial seed value, then `odp_random_test_data()` will return the same
+sequence of data bytes.
=== Capability inquiries
-ODP provides an API interface `odp_crypto_capability()` to inquire implementation’s
-crypto capabilities. This interface returns a bitmask for supported algorithms
-and hardware backed algorithms.
+ODP provides the API `odp_crypto_capability()` to inquire the implementation’s
+crypto capabilities. This interface returns a the maximum number of crypto
+sessions supported as well as bitmasks for supported algorithms and hardware
+backed algorithms.
\ No newline at end of file
commit ea51e9f8dba20f06b56c3e293b5b1eebc01e3d71
Author: Bill Fischofer <bill.fischofer(a)linaro.org>
Date: Mon Dec 12 09:06:16 2016 -0600
doc: userguide: move crypto documentation to its own sub-document
Signed-off-by: Bill Fischofer <bill.fischofer(a)linaro.org>
Reviewed-by: Petri Savolainen <petri.savolainen(a)nokia.com>
Signed-off-by: Maxim Uvarov <maxim.uvarov(a)linaro.org>
diff --git a/doc/users-guide/Makefile.am b/doc/users-guide/Makefile.am
index a01c717..01b4df3 100644
--- a/doc/users-guide/Makefile.am
+++ b/doc/users-guide/Makefile.am
@@ -2,6 +2,7 @@ include ../Makefile.inc
SRC = $(top_srcdir)/doc/users-guide/users-guide.adoc \
$(top_srcdir)/doc/users-guide/users-guide-cls.adoc \
+ $(top_srcdir)/doc/users-guide/users-guide-crypto.adoc \
$(top_srcdir)/doc/users-guide/users-guide-packet.adoc \
$(top_srcdir)/doc/users-guide/users-guide-pktio.adoc \
$(top_srcdir)/doc/users-guide/users-guide-timer.adoc \
diff --git a/doc/users-guide/users-guide-crypto.adoc b/doc/users-guide/users-guide-crypto.adoc
new file mode 100644
index 0000000..04b3e87
--- /dev/null
+++ b/doc/users-guide/users-guide-crypto.adoc
@@ -0,0 +1,71 @@
+== Cryptographic services
+
+ODP provides APIs to perform cryptographic operations required by various
+communication protocols (e.g. IPSec). ODP cryptographic APIs are session based.
+
+ODP provides APIs for following cryptographic services:
+
+* Ciphering
+* Authentication/data integrity via Keyed-Hashing (HMAC)
+* Random number generation
+* Crypto capability inquiries
+
+=== Crypto Sessions
+
+To apply a cryptographic operation to a packet a session must be created. All
+packets processed by a session share the parameters that define the session.
+
+ODP supports synchronous and asynchronous crypto sessions. For asynchronous
+sessions, the output of crypto operation is posted in a queue defined as
+the completion queue in its session parameters.
+
+ODP crypto APIs support chained operation sessions in which hashing and ciphering
+both can be achieved using a single session and operation call. The order of
+cipher and hashing can be controlled by the `auth_cipher_text` session parameter.
+
+Other Session parameters include algorithms, keys, initialization vector
+(optional), encode or decode, output queue for async mode and output packet pool
+for allocation of an output packet if required.
+
+=== Crypto operations
+
+After session creation, a cryptographic operation can be applied to a packet
+using the `odp_crypto_operation()` API. Applications may indicate a preference
+for synchronous or asynchronous processing in the session's `pref_mode` parameter.
+However crypto operations may complete synchronously even if an asynchronous
+preference is indicated, and applications must examine the `posted` output
+parameter from `odp_crypto_operation()` to determine whether the operation has
+completed or if an `ODP_EVENT_CRYPTO_COMPL` notification is expected. In the case
+of an async operation, the `posted` output parameter will be set to true.
+
+
+The operation arguments specify for each packet the areas that are to be
+encrypted or decrypted and authenticated. Also, there is an option of overriding
+the initialization vector specified in session parameters.
+
+An operation can be executed in in-place, out-of-place or new buffer mode.
+In in-place mode output packet is same as the input packet.
+In case of out-of-place mode output packet is different from input packet as
+specified by the application, while in new buffer mode implementation allocates
+a new output buffer from the session’s output pool.
+
+The application can also specify a context associated with a given operation that
+will be retained during async operation and can be retrieved via the completion
+event.
+
+Results of an asynchronous session will be posted as completion events to the
+session’s completion queue, which can be accessed directly or via the ODP
+scheduler. The completion event contains the status of the operation and the
+result. The application has the responsibility to free the completion event.
+
+=== Random number Generation
+
+ODP provides an API `odp_random_data()` to generate random data bytes. It has
+an argument to specify whether to use system entropy source for random number
+generation or not.
+
+=== Capability inquiries
+
+ODP provides an API interface `odp_crypto_capability()` to inquire implementation’s
+crypto capabilities. This interface returns a bitmask for supported algorithms
+and hardware backed algorithms.
diff --git a/doc/users-guide/users-guide.adoc b/doc/users-guide/users-guide.adoc
index 9a427fa..41c57d1 100755
--- a/doc/users-guide/users-guide.adoc
+++ b/doc/users-guide/users-guide.adoc
@@ -1018,77 +1018,7 @@ include::users-guide-pktio.adoc[]
include::users-guide-timer.adoc[]
-== Cryptographic services
-
-ODP provides APIs to perform cryptographic operations required by various
-communication protocols (e.g. IPSec). ODP cryptographic APIs are session based.
-
-ODP provides APIs for following cryptographic services:
-
-* Ciphering
-* Authentication/data integrity via Keyed-Hashing (HMAC)
-* Random number generation
-* Crypto capability inquiries
-
-=== Crypto Sessions
-
-To apply a cryptographic operation to a packet a session must be created. All
-packets processed by a session share the parameters that define the session.
-
-ODP supports synchronous and asynchronous crypto sessions. For asynchronous
-sessions, the output of crypto operation is posted in a queue defined as
-the completion queue in its session parameters.
-
-ODP crypto APIs support chained operation sessions in which hashing and ciphering
-both can be achieved using a single session and operation call. The order of
-cipher and hashing can be controlled by the `auth_cipher_text` session parameter.
-
-Other Session parameters include algorithms, keys, initialization vector
-(optional), encode or decode, output queue for async mode and output packet pool
-for allocation of an output packet if required.
-
-=== Crypto operations
-
-After session creation, a cryptographic operation can be applied to a packet
-using the `odp_crypto_operation()` API. Applications may indicate a preference
-for synchronous or asynchronous processing in the session's `pref_mode` parameter.
-However crypto operations may complete synchronously even if an asynchronous
-preference is indicated, and applications must examine the `posted` output
-parameter from `odp_crypto_operation()` to determine whether the operation has
-completed or if an `ODP_EVENT_CRYPTO_COMPL` notification is expected. In the case
-of an async operation, the `posted` output parameter will be set to true.
-
-
-The operation arguments specify for each packet the areas that are to be
-encrypted or decrypted and authenticated. Also, there is an option of overriding
-the initialization vector specified in session parameters.
-
-An operation can be executed in in-place, out-of-place or new buffer mode.
-In in-place mode output packet is same as the input packet.
-In case of out-of-place mode output packet is different from input packet as
-specified by the application, while in new buffer mode implementation allocates
-a new output buffer from the session’s output pool.
-
-The application can also specify a context associated with a given operation that
-will be retained during async operation and can be retrieved via the completion
-event.
-
-Results of an asynchronous session will be posted as completion events to the
-session’s completion queue, which can be accessed directly or via the ODP
-scheduler. The completion event contains the status of the operation and the
-result. The application has the responsibility to free the completion event.
-
-=== Random number Generation
-
-ODP provides an API `odp_random_data()` to generate random data bytes. It has
-an argument to specify whether to use system entropy source for random number
-generation or not.
-
-=== Capability inquiries
-
-ODP provides an API interface `odp_crypto_capability()` to inquire implementation’s
-crypto capabilities. This interface returns a bitmask for supported algorithms
-and hardware backed algorithms.
+include::users-guide-crypto.adoc[]
include::users-guide-tm.adoc[]
commit 58a2fd9358675a54f2ed0f43ef3574a7b4a2c7dd
Author: Bill Fischofer <bill.fischofer(a)linaro.org>
Date: Mon Dec 12 09:06:15 2016 -0600
api: random: add explicit controls over random data
Rework the odp_random_data() API to replace the use_entropy with an
explicit odp_random_kind parameter that controls the type of random
desired. Two new APIs are also introduced:
- odp_random_max_kind() returns the maximum kind of random data available
- odp_random_test_data() permits applications to generate repeatable
random sequences for testing purposes
Signed-off-by: Bill Fischofer <bill.fischofer(a)linaro.org>
Reviewed-by: Petri Savolainen <petri.savolainen(a)nokia.com>
Signed-off-by: Maxim Uvarov <maxim.uvarov(a)linaro.org>
diff --git a/include/odp/api/spec/random.h b/include/odp/api/spec/random.h
index 00fa15b..4765475 100644
--- a/include/odp/api/spec/random.h
+++ b/include/odp/api/spec/random.h
@@ -24,18 +24,82 @@ extern "C" {
*/
/**
+ * Random kind selector
+ *
+ * The kind of random denotes the statistical quality of the random data
+ * returned. Basic random simply appears uniformly distributed, Cryptographic
+ * random is statistically random and suitable for use by cryptographic
+ * functions. True random is generated from a hardware entropy source rather
+ * than an algorithm and is thus completely unpredictable. These form a
+ * hierarchy where higher quality data is presumably more costly to generate
+ * than lower quality data.
+ */
+typedef enum {
+ /** Basic random, presumably pseudo-random generated by SW. This
+ * is the lowest kind of random */
+ ODP_RANDOM_BASIC,
+ /** Cryptographic quality random */
+ ODP_RANDOM_CRYPTO,
+ /** True random, generated from a HW entropy source. This is the
+ * highest kind of random */
+ ODP_RANDOM_TRUE,
+} odp_random_kind_t;
+
+/**
+ * Query random max kind
+ *
+ * Implementations support the returned max kind and all kinds weaker than it.
+ *
+ * @return kind The maximum odp_random_kind_t supported by this implementation
+ */
+odp_random_kind_t odp_random_max_kind(void);
+
+/**
* Generate random byte data
*
+ * The intent in supporting different kinds of random data is to allow
+ * tradeoffs between performance and the quality of random data needed. The
+ * assumption is that basic random is cheap while true random is relatively
+ * expensive in terms of time to generate, with cryptographic random being
+ * something in between. Implementations that support highly efficient true
+ * random are free to use this for all requested kinds. So it is always
+ * permissible to "upgrade" a random data request, but never to "downgrade"
+ * such requests.
+ *
* @param[out] buf Output buffer
- * @param size Size of output buffer
- * @param use_entropy Use entropy
+ * @param len Length of output buffer in bytes
+ * @param kind Specifies the type of random data required. Request
+ * is expected to fail if the implementation is unable to
+ * provide the requested type.
+ *
+ * @return Number of bytes written
+ * @retval <0 on failure
+ */
+int32_t odp_random_data(uint8_t *buf, uint32_t len, odp_random_kind_t kind);
+
+/**
+ * Generate repeatable random data for testing purposes
+ *
+ * For testing purposes it is often useful to generate "random" sequences that
+ * are repeatable. This is accomplished by supplying a seed value that is used
+ * for pseudo-random data generation. The caller-provided seed value is
+ * updated for each call to continue the sequence. Restarting a series of
+ * calls with the same initial seed value will generate the same sequence of
+ * random test data.
+ *
+ * This function returns data of ODP_RANDOM_BASIC quality and should be used
+ * only for testing purposes. Use odp_random_data() for production.
*
- * @todo Define the implication of the use_entropy parameter
+ * @param[out] buf Output buffer
+ * @param len Length of output buffer in bytes
+ * @param[in,out] seed Seed value to use. This must be a thread-local
+ * variable. Results are undefined if multiple threads
+ * call this routine with the same seed variable.
*
* @return Number of bytes written
* @retval <0 on failure
*/
-int32_t odp_random_data(uint8_t *buf, int32_t size, odp_bool_t use_entropy);
+int32_t odp_random_test_data(uint8_t *buf, uint32_t len, uint64_t *seed);
/**
* @}
diff --git a/platform/linux-generic/odp_crypto.c b/platform/linux-generic/odp_crypto.c
index 6b7d60e..5808d16 100644
--- a/platform/linux-generic/odp_crypto.c
+++ b/platform/linux-generic/odp_crypto.c
@@ -4,6 +4,7 @@
* SPDX-License-Identifier: BSD-3-Clause
*/
+#include <odp_posix_extensions.h>
#include <odp/api/crypto.h>
#include <odp_internal.h>
#include <odp/api/atomic.h>
@@ -19,6 +20,7 @@
#include <odp_packet_internal.h>
#include <string.h>
+#include <stdlib.h>
#include <openssl/des.h>
#include <openssl/rand.h>
@@ -999,12 +1001,48 @@ int odp_crypto_term_global(void)
return rc;
}
-int32_t
-odp_random_data(uint8_t *buf, int32_t len, odp_bool_t use_entropy ODP_UNUSED)
+odp_random_kind_t odp_random_max_kind(void)
{
- int32_t rc;
- rc = RAND_bytes(buf, len);
- return (1 == rc) ? len /*success*/: -1 /*failure*/;
+ return ODP_RANDOM_CRYPTO;
+}
+
+int32_t odp_random_data(uint8_t *buf, uint32_t len, odp_random_kind_t kind)
+{
+ int rc;
+
+ switch (kind) {
+ case ODP_RANDOM_BASIC:
+ RAND_pseudo_bytes(buf, len);
+ return len;
+
+ case ODP_RANDOM_CRYPTO:
+ rc = RAND_bytes(buf, len);
+ return (1 == rc) ? (int)len /*success*/: -1 /*failure*/;
+
+ case ODP_RANDOM_TRUE:
+ default:
+ return -1;
+ }
+}
+
+int32_t odp_random_test_data(uint8_t *buf, uint32_t len, uint64_t *seed)
+{
+ union {
+ uint32_t rand_word;
+ uint8_t rand_byte[4];
+ } u;
+ uint32_t i = 0, j;
+ uint32_t seed32 = (*seed) & 0xffffffff;
+
+ while (i < len) {
+ u.rand_word = rand_r(&seed32);
+
+ for (j = 0; j < 4 && i < len; j++, i++)
+ *buf++ = u.rand_byte[j];
+ }
+
+ *seed = seed32;
+ return len;
}
odp_crypto_compl_t odp_crypto_compl_from_event(odp_event_t ev)
diff --git a/test/common_plat/validation/api/random/random.c b/test/common_plat/validation/api/random/random.c
index 7572366..a0e2ef7 100644
--- a/test/common_plat/validation/api/random/random.c
+++ b/test/common_plat/validation/api/random/random.c
@@ -13,12 +13,58 @@ void random_test_get_size(void)
int32_t ret;
uint8_t buf[32];
- ret = odp_random_data(buf, sizeof(buf), false);
+ ret = odp_random_data(buf, sizeof(buf), ODP_RANDOM_BASIC);
CU_ASSERT(ret == sizeof(buf));
}
+void random_test_kind(void)
+{
+ int32_t rc;
+ uint8_t buf[4096];
+ uint32_t buf_size = sizeof(buf);
+ odp_random_kind_t max_kind = odp_random_max_kind();
+
+ rc = odp_random_data(buf, buf_size, max_kind);
+ CU_ASSERT(rc > 0);
+
+ switch (max_kind) {
+ case ODP_RANDOM_BASIC:
+ rc = odp_random_data(buf, 4, ODP_RANDOM_CRYPTO);
+ CU_ASSERT(rc < 0);
+ /* Fall through */
+
+ case ODP_RANDOM_CRYPTO:
+ rc = odp_random_data(buf, 4, ODP_RANDOM_TRUE);
+ CU_ASSERT(rc < 0);
+ break;
+
+ default:
+ break;
+ }
+}
+
+void random_test_repeat(void)
+{
+ uint8_t buf1[1024];
+ uint8_t buf2[1024];
+ int32_t rc;
+ uint64_t seed1 = 12345897;
+ uint64_t seed2 = seed1;
+
+ rc = odp_random_test_data(buf1, sizeof(buf1), &seed1);
+ CU_ASSERT(rc == sizeof(buf1));
+
+ rc = odp_random_test_data(buf2, sizeof(buf2), &seed2);
+ CU_ASSERT(rc == sizeof(buf2));
+
+ CU_ASSERT(seed1 == seed2);
+ CU_ASSERT(memcmp(buf1, buf2, sizeof(buf1)) == 0);
+}
+
odp_testinfo_t random_suite[] = {
ODP_TEST_INFO(random_test_get_size),
+ ODP_TEST_INFO(random_test_kind),
+ ODP_TEST_INFO(random_test_repeat),
ODP_TEST_INFO_NULL,
};
diff --git a/test/common_plat/validation/api/random/random.h b/test/common_plat/validation/api/random/random.h
index 26202cc..c4bca78 100644
--- a/test/common_plat/validation/api/random/random.h
+++ b/test/common_plat/validation/api/random/random.h
@@ -11,6 +11,8 @@
/* test functions: */
void random_test_get_size(void);
+void random_test_kind(void);
+void random_test_repeat(void);
/* test arrays: */
extern odp_testinfo_t random_suite[];
-----------------------------------------------------------------------
Summary of changes:
doc/users-guide/Makefile.am | 1 +
doc/users-guide/users-guide-crypto.adoc | 122 ++++++++++++++++++++++++
doc/users-guide/users-guide.adoc | 72 +-------------
include/odp/api/spec/random.h | 72 +++++++++++++-
platform/linux-generic/odp_crypto.c | 48 +++++++++-
test/common_plat/validation/api/random/random.c | 48 +++++++++-
test/common_plat/validation/api/random/random.h | 2 +
7 files changed, 284 insertions(+), 81 deletions(-)
create mode 100644 doc/users-guide/users-guide-crypto.adoc
hooks/post-receive
--
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "".
The branch, api-next has been updated
via 9fa4b3c5efa041351ba915ca35b3dfe252ecb34c (commit)
from 983712f43845f8fa7967039d2fd067f9a3ecba20 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
-----------------------------------------------------------------------
Summary of changes:
platform/linux-generic/include/odp_buffer_internal.h | 7 +++----
platform/linux-generic/pktio/ipc.c | 7 -------
2 files changed, 3 insertions(+), 11 deletions(-)
hooks/post-receive
--
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "".
The branch, next has been updated
via 9fa4b3c5efa041351ba915ca35b3dfe252ecb34c (commit)
from 983712f43845f8fa7967039d2fd067f9a3ecba20 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 9fa4b3c5efa041351ba915ca35b3dfe252ecb34c
Author: Maxim Uvarov <maxim.uvarov(a)linaro.org>
Date: Fri Dec 16 17:27:35 2016 +0300
linux-gen: pktio ipc: fix clang build
clang is more clever on setting and not using variables,
so it traps compilation. Also buffers header almost everywhere
reference by pointer so size of it should not impact on
performance.
Signed-off-by: Maxim Uvarov <maxim.uvarov(a)linaro.org>
Reviewed-and-tested-by: Bill Fischofer <bill.fischofer(a)linaro.org>
diff --git a/platform/linux-generic/include/odp_buffer_internal.h b/platform/linux-generic/include/odp_buffer_internal.h
index 903f0a7..4cc51d3 100644
--- a/platform/linux-generic/include/odp_buffer_internal.h
+++ b/platform/linux-generic/include/odp_buffer_internal.h
@@ -64,11 +64,10 @@ struct odp_buffer_hdr_t {
struct {
void *hdr;
uint8_t *data;
-#ifdef _ODP_PKTIO_IPC
- /* ipc mapped process can not walk over pointers,
- * offset has to be used */
+ /* Used only if _ODP_PKTIO_IPC is set.
+ * ipc mapped process can not walk over pointers,
+ * offset has to be used */
uint64_t ipc_data_offset;
-#endif
uint32_t len;
} seg[CONFIG_PACKET_MAX_SEGS];
diff --git a/platform/linux-generic/pktio/ipc.c b/platform/linux-generic/pktio/ipc.c
index 5f26b56..c9df043 100644
--- a/platform/linux-generic/pktio/ipc.c
+++ b/platform/linux-generic/pktio/ipc.c
@@ -459,12 +459,7 @@ static int ipc_pktio_recv_lockless(pktio_entry_t *pktio_entry,
if (odp_unlikely(pool == ODP_POOL_INVALID))
ODP_ABORT("invalid pool");
-#ifdef _ODP_PKTIO_IPC
data_pool_off = phdr->buf_hdr.seg[0].ipc_data_offset;
-#else
- /* compile all function code even if ipc disabled with config */
- data_pool_off = 0;
-#endif
pkt = odp_packet_alloc(pool, phdr->frame_len);
if (odp_unlikely(pkt == ODP_PACKET_INVALID)) {
@@ -590,7 +585,6 @@ static int ipc_pktio_send_lockless(pktio_entry_t *pktio_entry,
data_pool_off = (uint8_t *)pkt_hdr->buf_hdr.seg[0].data -
(uint8_t *)odp_shm_addr(pool->shm);
-#ifdef _ODP_PKTIO_IPC
/* compile all function code even if ipc disabled with config */
pkt_hdr->buf_hdr.seg[0].ipc_data_offset = data_pool_off;
IPC_ODP_DBG("%d/%d send packet %llx, pool %llx,"
@@ -598,7 +592,6 @@ static int ipc_pktio_send_lockless(pktio_entry_t *pktio_entry,
i, len,
odp_packet_to_u64(pkt), odp_pool_to_u64(pool_hdl),
pkt_hdr, pkt_hdr->buf_hdr.seg[0].ipc_data_offset);
-#endif
}
/* Put packets to ring to be processed by other process. */
-----------------------------------------------------------------------
Summary of changes:
platform/linux-generic/include/odp_buffer_internal.h | 7 +++----
platform/linux-generic/pktio/ipc.c | 7 -------
2 files changed, 3 insertions(+), 11 deletions(-)
hooks/post-receive
--
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "".
The branch, api-next has been updated
via 983712f43845f8fa7967039d2fd067f9a3ecba20 (commit)
from 7e0461544a5bb9052d84843c5043c68d34b17ba3 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 983712f43845f8fa7967039d2fd067f9a3ecba20
Author: Maxim Uvarov <maxim.uvarov(a)linaro.org>
Date: Wed Dec 14 22:57:57 2016 +0300
linux-gen: pktio ipc: tests: remove comment about master-slave
Implementation take care which process to name master and which
slave. Comment is useless.
Signed-off-by: Maxim Uvarov <maxim.uvarov(a)linaro.org>
Reviewed-and-tested-by: Bill Fischofer <bill.fischofer(a)linaro.org>
diff --git a/test/linux-generic/pktio_ipc/pktio_ipc1.c b/test/linux-generic/pktio_ipc/pktio_ipc1.c
index 838b672..705c205 100644
--- a/test/linux-generic/pktio_ipc/pktio_ipc1.c
+++ b/test/linux-generic/pktio_ipc/pktio_ipc1.c
@@ -52,9 +52,6 @@ static int pktio_run_loop(odp_pool_t pool)
start_cycle = odp_time_local();
current_cycle = start_cycle;
- /* slave process should always be run after master process to be
- * able to create the same pktio.
- */
for (;;) {
if (run_time_sec) {
cycle = odp_time_local();
diff --git a/test/linux-generic/pktio_ipc/pktio_ipc2.c b/test/linux-generic/pktio_ipc/pktio_ipc2.c
index fb6f994..daf3841 100644
--- a/test/linux-generic/pktio_ipc/pktio_ipc2.c
+++ b/test/linux-generic/pktio_ipc/pktio_ipc2.c
@@ -49,9 +49,6 @@ static int ipc_second_process(int master_pid)
wait = odp_time_local_from_ns(run_time_sec * ODP_TIME_SEC_IN_NS);
start_cycle = odp_time_local();
- /* slave process should always be run after master process to be
- * able to create the same pktio.
- */
for (;;) {
/* exit loop if time specified */
if (run_time_sec) {
-----------------------------------------------------------------------
Summary of changes:
test/linux-generic/pktio_ipc/pktio_ipc1.c | 3 ---
test/linux-generic/pktio_ipc/pktio_ipc2.c | 3 ---
2 files changed, 6 deletions(-)
hooks/post-receive
--
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "".
The branch, api-next has been updated
via 03ec3dcd7ed9d55b91d58d6969114e7de71b88fe (commit)
via e454f36a4a7c70dafd87eab03b3ba740dc10860a (commit)
via 27a05a1d61f3b7e4d58ac0e89db43db069dcc9a3 (commit)
from 362035d60fda8a566636aa5ba58250a8fae9169b (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 03ec3dcd7ed9d55b91d58d6969114e7de71b88fe
Merge: 362035d e454f36
Author: Maxim Uvarov <maxim.uvarov(a)linaro.org>
Date: Thu Dec 15 22:28:01 2016 +0300
Merge branch 'master' into api-next
-----------------------------------------------------------------------
Summary of changes:
configure.ac | 1 -
example/traffic_mgmt/odp_traffic_mgmt.c | 20 ++++++++++++--------
2 files changed, 12 insertions(+), 9 deletions(-)
hooks/post-receive
--
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "".
The branch, master has been updated
via e454f36a4a7c70dafd87eab03b3ba740dc10860a (commit)
from 27a05a1d61f3b7e4d58ac0e89db43db069dcc9a3 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit e454f36a4a7c70dafd87eab03b3ba740dc10860a
Author: Maxim Uvarov <maxim.uvarov(a)linaro.org>
Date: Tue Dec 13 16:34:31 2016 +0300
configure.ac: do not disable shared lib for non abi mode
After discussion on mailing list there is case to support
shared library for non abi compatibility mode.
Signed-off-by: Maxim Uvarov <maxim.uvarov(a)linaro.org>
Reviewed-by: Bill Fischofer <bill.fischofer(a)linaro.org>
diff --git a/configure.ac b/configure.ac
index 20ec479..54d62f7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -253,7 +253,6 @@ AC_ARG_ENABLE([abi-compat],
[if test "x$enableval" = "xno"; then
ODP_ABI_COMPAT=0
abi_compat=no
- enable_shared=no
#if there is no ABI compatibility the .so numbers are meaningless
ODP_LIBSO_VERSION=0:0:0
fi])
-----------------------------------------------------------------------
Summary of changes:
configure.ac | 1 -
1 file changed, 1 deletion(-)
hooks/post-receive
--