Re: [lng-odp] [PATCH v1 0/9] Rework the way ODP links with other libraries
The m4 branch works without problems, thanks! -Matias > On 5 Jun 2017, at 17:03, Dmitry Eremin-Solenikov > wrote: > > On 05.06.2017 17:00, Elo, Matias (Nokia - FI/Espoo) wrote: >> I already left the office but I'll test it first thing in the morning. > > Thank you! > >> >> -Matias >> >>> On 5 Jun 2017, at 16.51, Dmitry Eremin-Solenikov >>> wrote: >>> On 05.06.2017 16:34, Elo, Matias (Nokia - FI/Espoo) wrote: > On 5 Jun 2017, at 16:24, Dmitry Eremin-Solenikov > wrote: > > On 05.06.2017 16:22, Elo, Matias (Nokia - FI/Espoo) wrote: >> >>> On 5 Jun 2017, at 16:11, Dmitry Eremin-Solenikov >>> wrote: >>> >>> $ nm test/common_plat/performance/odp_l2fwd | grep vdrv >>> 001e7fd0 T rte_eal_vdrv_register >>> 001e8000 T rte_eal_vdrv_unregister >>> 0001bfe0 t vdrvinitfn_cryptodev_null_pmd_drv >>> 0001bcf0 t vdrvinitfn_pmd_af_packet_drv >>> 0001bd40 t vdrvinitfn_pmd_bond_drv >>> 0001bfb0 t vdrvinitfn_pmd_null_drv >>> 0001c010 t vdrvinitfn_pmd_pcap_drv >>> 0001c080 t vdrvinitfn_pmd_ring_drv >>> 0001c0d0 t vdrvinitfn_pmd_tap_drv >>> 0001c100 t vdrvinitfn_pmd_vhost_drv >>> 0001c150 t vdrvinitfn_virtio_user_driver >> >> For me: >> >> $ ./configure --enable-test-perf --enable-test-vald --enable-test-cpp >> --enable-test-example --enable-test-helper --enable-helper-linux >> --with-cunit-path=/home/NNN/CUnitHome >> --with-netmap-path=/home/NNN/dev/netmap.git >> --with-dpdk-path=/home/NNN/dev/dpdk.git/x86_64-native-linuxapp-gcc >> --prefix=/home/NNN/odp_install > > Just out of curiosity, could you please do make distclean, clean rebuild > with V=1 and then send me > - the rebuild log. > - config.log > - lib/libodp-linux.la Here you go. >>> >>> Pushed updated m4 branch. Could you please check it? >>> >>> >>> -- >>> With best wishes >>> Dmitry > > > -- > With best wishes > Dmitry
Re: [lng-odp] [RFC, API-NEXT v3 1/1] comp: compression interface
Do we have any more comments on same?
Petri
Could you get time to review feedback?
Can we consider v3 as accepted?
Thanks
Shally
On Thu, Jun 1, 2017 at 10:05 PM, shally verma
wrote:
> Re-sending with updated comments.
>
> Regards
> Shally
>
> On Thu, Jun 1, 2017 at 7:58 PM, Verma, Shally
> wrote:
>>
>> Regards
>> Shally
>>
>> -Original Message-
>> From: Savolainen, Petri (Nokia - FI/Espoo)
>> [mailto:petri.savolai...@nokia.com]
>> Sent: 01 June 2017 18:20
>> To: Shally Verma ; lng-odp@lists.linaro.org
>> Cc: Challa, Mahipal ; Narayana, Prasad Athreya
>> ; Verma, Shally
>> Subject: RE: [lng-odp] [RFC, API-NEXT v3 1/1] comp: compression interface
>>
>>
>>
>> > -Original Message-
>> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>> > Shally Verma
>> > Sent: Monday, May 22, 2017 9:55 AM
>> > To: lng-odp@lists.linaro.org
>> > Cc: Mahipal Challa ; pathr...@cavium.com; Shally
>> > Verma
>> > Subject: [lng-odp] [RFC, API-NEXT v3 1/1] comp: compression interface
>> >
>>
>> A short description (5-10 lines) about the new API should be added here.
>>
>> For example: what kind of compression this API offers. How it's used.
>> Which kind of applications typical use it.
>>
>> Current ODP Comp interface is designed to support widely used lossless
>> data compression schemes : deflate, zlib and lzs.
>> Typical applications include (but not limited to ) IPComp, other
>> application and transport layer protocols such as HTTP compression.
>>
>> Changes from V2:
>> Add separate API for sync and async operation,
>> Add separate API to load dictionary,
>> Removed SHA only support from compression interface,
>> Rename SHA operations as hash operation.
>> Add reference odp_packet_data_range_t for accessing packet buffer
>>
>>
>> > Signed-off-by: Shally Verma
>> > Signed-off-by: Mahipal Challa
>> > ---
>> > include/odp/api/spec/comp.h | 740
>> >
>> > 1 file changed, 740 insertions(+)
>> >
>> > diff --git a/include/odp/api/spec/comp.h b/include/odp/api/spec/comp.h
>> > new file mode 100644 index 000..6c13ad4
>> > --- /dev/null
>> > +++ b/include/odp/api/spec/comp.h
>> > @@ -0,0 +1,740 @@
>> > +/*
>> > + */
>> > +
>> > +/**
>> > + * @file
>> > + *
>> > + * ODP Compression
>> > + */
>> > +
>> > +#ifndef ODP_API_COMP_H_
>> > +#define ODP_API_COMP_H_
>> > +
>> > +#include
>> > +#include
>> > +#include
>> > +
>> > +#ifdef __cplusplus
>> > +extern "C" {
>> > +#endif
>> > +
>> > +/** @defgroup odp_compression ODP COMP
>> > + * ODP Compression defines interface to compress/decompress along
>> > +with
>> > hash
>> > + * operations.
>> > + *
>> > + * Compression here implicitly refer to both compression and
>> > decompression.
>>
>> Typo: implicitly.
>>
>> Actually, you could just say: "Compression API supports both compression
>> and decompression operations."
>>
>>
>> > + * Example, compression algo 'deflate' mean both 'deflate' and
>> > 'inflate'.
>> > + *
>> > + * if opcode = ODP_COMP_COMPRESS, then it will Compress and/or apply
>> > hash,
>> > + * if opcode = ODP_COMP_DECOMPRESS, then it will Decompress and/or
>> > + apply
>> > + * hash.
>>
>> I think it would be better to have separate operations for compress and
>> decompress. Application would typically call one on ingress side and the
>> other on egress side, or maybe only one of those. Dual functionality would
>> make sense if every second packet on the same code path would be compressed
>> and every second decompressed, but I think that's not the case.
>>
>> Application will create either Compression session or Decompression
>> session. so if two operations are requested simultaneously, then two
>> sessions would be created where each session will have its specific
>> operation context. So this way Compress and Decompress will be two separate
>> operations.
>
>
>>
>> > + *
>> > + * Current version of interface allow Compression ONLY,and
>> > + * both Compression + hash ONLY sessions.
>>
>> What this comment tries to say. Decompression is not supported at all ? Or
>
> - Decompression and Decompression+hash supported
>
>> "hashing only" is not supported yet.
>
> -Yes "hashing only" not supported.
>
>> "Hashing only" should not be a target for this API.
>> - Yes. it is not.
>
>
>>
>>
>>
>> > + *
>> > + * Macros, enums, types and operations to utilise compression.
>> > + * @{
>> > + */
>> > +
>> > +/**
>> > + * @def ODP_COMP_SESSION_INVALID
>> > + * Invalid session handle
>> > + */
>> > +
>> > +/**
>> > + * @typedef odp_comp_session_t (platform dependent)
>> > + * Comp API opaque session handle
>>
>> "Compression session handle"
>>
>> No need to mention opaque, as all ODP handles are opaque.
>> Ack.
>>
>> > + */
>> > +
>> > +/**
>> > + * @typedef odp_comp_compl_t
>> > +* Compression API completion event (platform dependent)
>>
>> Remove "platform dependent", all opaque types are like that.
>> Ack.
>>
>> > +*/
>> > +
>> > +/**
>> > + * Compression API operation mode
>> > +
Re: [lng-odp] [PATCH v3 0/2] GCC 7 fixes
On 06/05 22:29:22, Bill Fischofer wrote: > On Mon, Jun 5, 2017 at 9:32 PM, Brian Brooks wrote: > > On 06/05 18:40:02, Bill Fischofer wrote: > >> After installing a copy of GCC 7, It looks like this patch is an > >> incomplete fix. With this patch applied older GCC 6.3.0 continues to > >> work fine, but GCC 7.0.1 generates the following errors: > >> > >> Making all in platform/linux-generic > >> make[1]: Entering directory > >> '/home/bill/linaro/gcc7fix/platform/linux-generic' > >> CC pktio/ipc.lo > >> pktio/ipc.c: In function ‘ipc_close’: > >> pktio/ipc.c:698:33: error: ‘%s’ directive output may be truncated > >> writing up to 255 bytes into a region of size 32 > >> [-Werror=format-truncation=] > >>snprintf(name, sizeof(name), "%s", dev); > > > > It looks like ./bootstrap might not have been run after applying the patch? > > I just retried the build on a clean directory with ./bootstrap and > ./configure and get the same errors. Can you post the bottom part of ./configure output? Here is what I see: cc: gcc cc version: 7.1.1 cppflags: am_cppflags: am_cxxflags:-std=c++11 cflags: -g -O2 am_cflags: -pthread -DHAVE_PCAP -DIMPLEMENTATION_NAME=odp-linux -DODP_DEBUG_PRINT=0 -DODPH_DEBUG_PRINT=0 -DODP_DEBUG=0 -W -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wold-style-definition -Wpointer-arith -Wcast-align -Wnested-externs -Wcast-qual -Wformat-nonliteral -Wformat-security -Wundef -Wwrite-strings -std=c99 -Wimplicit-fallthrough=0 -Wformat-truncation=0 -Wformat-overflow=0 -mcx16 ldflags: am_ldflags: -latomic -pthread -lrt libs: -lrt -lcunit -lcrypto -lpcap defs: -DHAVE_CONFIG_H static libraries: yes shared libraries: yes ABI compatible: yes cunit: yes test_vald: yes test_perf: yes test_perf_proc: yes test_cpp: yes test_helper:yes test_example: yes user_guides:no
Re: [lng-odp] [PATCH v3 0/2] GCC 7 fixes
On Mon, Jun 5, 2017 at 9:32 PM, Brian Brooks wrote: > On 06/05 18:40:02, Bill Fischofer wrote: >> After installing a copy of GCC 7, It looks like this patch is an >> incomplete fix. With this patch applied older GCC 6.3.0 continues to >> work fine, but GCC 7.0.1 generates the following errors: >> >> Making all in platform/linux-generic >> make[1]: Entering directory >> '/home/bill/linaro/gcc7fix/platform/linux-generic' >> CC pktio/ipc.lo >> pktio/ipc.c: In function ‘ipc_close’: >> pktio/ipc.c:698:33: error: ‘%s’ directive output may be truncated >> writing up to 255 bytes into a region of size 32 >> [-Werror=format-truncation=] >>snprintf(name, sizeof(name), "%s", dev); > > It looks like ./bootstrap might not have been run after applying the patch? I just retried the build on a clean directory with ./bootstrap and ./configure and get the same errors.
Re: [lng-odp] [NEXT PATCHv3] changelog: updates for odp v1.15.0.0
Thanks. Corrected in v4. It turns out that this same typo exists in a couple of places in the spec crypto.h file so I've posted a patch to correct that too. On Mon, Jun 5, 2017 at 9:56 PM, Yi He wrote: > Hi, Bill, two minor issues as below. > > On 6 June 2017 at 00:12, Bill Fischofer wrote: >> >> Signed-off-by: Bill Fischofer >> --- >> CHANGELOG | 264 >> ++ >> 1 file changed, 264 insertions(+) >> >> diff --git a/CHANGELOG b/CHANGELOG >> index a550a723..4a7759e2 100644 >> --- a/CHANGELOG >> +++ b/CHANGELOG >> @@ -1,3 +1,267 @@ >> +== OpenDataPlane (1.15.0.0) >> +=== New Features >> +ODP v1.15.0.0 continues the preview of Tiger Moth, introducing new APIs >> and >> +extensions, as well as numerous bug fixes and functional improvements. >> + >> + Deprecation Framework >> +To permit smoother evolution of the ODP API specification, a deprecation >> +framework is introduced to permit controlled deprecation. >> + >> +When an ODP API or defined struct parameter is deprecated, ODP validation >> +tests will be updated to no longer use that API and instead use the >> +replacement API. By default, attempts to compile with the older >> API/feature >> +will fail and applications wishing to move to the new ODP release should >> be >> +updated to use the replacement API. To permit evaluation of new ODP >> +releases in advance of such updating, however, ODP supports the >> `configure` >> +option `--enable-deprecated`, which makes the obsolete APIs visible >> again. >> + >> +This feature will be used on a case-by-case basis and documented in the >> +release notes for each release that introduces replacement API(s). In >> general >> +the deprecated forms will not be maintained for more than a single >> release >> +cycle. After that they will no longer be present in the API specification >> and >> +the replacement forms must be used to compile with that level of the API >> +specification. >> + >> + APIs >> +A number of new and refined APIs are introduced in crypto, packet >> parsing, >> +and queue configuration: >> + >> += Crypto Enhancements >> +The ODP crypto APIs receive several enhancements in this release: >> + >> +== New Authentication Algorithms >> +Additional enumerations added for HMAC-SHA-1 and HMAC-SHA-512 >> authentication. >> + >> +== Deprecated Cipher/Authentication Algorithms >> +The following cipher/authentication algorithms have been deprecated in >> favor >> +of newer replacement algorithms: >> + >> +* `ODP_CIPHER_ALG_AES128_CBC` is replaced by `ODP_CIPHER_ALG_AES_CBC` >> +* `ODP_CIPHER_ALG_AES128_GCM` is replaced by `ODP_CIPHER_ALB_AES_GCM` > > > `ODP_CIPHER_ALB_AES_GCM` --> `ODP_CIPHER_ALG_AES_GCM`? > >> >> +* `ODP_AUTH_ALG_MD5_96` is replaced by `ODP_AUTH_ALG_MD5_HMAC` >> +* `ODP_AUTH_ALG_SHA256_128` is replaced by `ODP_AUTH_ALG_SHA256_HMAC` >> +* `ODP_AUTH_ALG_AES128_GCM1 is replaced by `ODP_AUTH_ALG_AES_GCM` >> + >> +== Deprecated Name for Crypto Parameter struct >> +`odp_crypto_op_params_t` is deprecated in favor of >> `odp_crypto_op_param_t` >> +for consistency with other ODP `param` structs. >> + >> +== Digest Length Session Parameter >> +`odp_crypto_session_param_t` adds the field `auth_digest_len` to permit >> +specification of the authentication digest length to be used for this >> +session. The `odp_crypto_auth_capa()` API returns the list of >> +supported digest lengths. > > > `odp_crypto_auth_capa()` API --> `odp_crypto_auth_capability()` API? > >> >> + >> +== Additional Authentication Data (AAD) >> +The `odp_crypto_op_param_t` struct adds an optional pointer and length >> for >> +AAD information. This allows applications to specify AAD information from >> +the list of supported lengths provided by `odp_crypto_auth_capability()`. >> + >> += Packet Range Data >> +The former `odp_crypto_data_range_t` type is deprecated and renamed to >> +`odp_packet_data_range_t` since it can be used to specify ranges for >> other >> +than crypto purposes. >> + >> += Parser Configuration >> +Applications may now specify the maximum packet layer of interest. For >> +example, a router may not care about anything beyond ISO Layer 3 in >> packets. >> +This can be used by ODP implementations to control the depth of packet >> +parsing needed by the application and may allow greater efficiency, >> +especially in software implementations. >> + >> +This is controlled by a new `odp_pktio_parser_layer_t` enum that is >> +part of the new `odp_pktio_parser_config_t` struct that is added to the >> +`odp_pktio_config_t` struct used by the `odp_pktio_config()` API. The >> +supported parser layers are also returned in this struct as part of the >> +`odp_pktio_capability_t` struct returned by the `odp_pktio_capability()` >> API. >> + >> += Queue Size Parameter >> +The `odp_queue_capability_t` struct returned by the >> `odp_queue_capability()` >> +API is enhanced as follows: >> +* The `max_queues` field is now defined to ret
[lng-odp] [NEXT PATCHv4] changelog: updates for odp v1.15.0.0
Signed-off-by: Bill Fischofer --- CHANGELOG | 264 ++ 1 file changed, 264 insertions(+) diff --git a/CHANGELOG b/CHANGELOG index a550a723..e9443053 100644 --- a/CHANGELOG +++ b/CHANGELOG @@ -1,3 +1,267 @@ +== OpenDataPlane (1.15.0.0) +=== New Features +ODP v1.15.0.0 continues the preview of Tiger Moth, introducing new APIs and +extensions, as well as numerous bug fixes and functional improvements. + + Deprecation Framework +To permit smoother evolution of the ODP API specification, a deprecation +framework is introduced to permit controlled deprecation. + +When an ODP API or defined struct parameter is deprecated, ODP validation +tests will be updated to no longer use that API and instead use the +replacement API. By default, attempts to compile with the older API/feature +will fail and applications wishing to move to the new ODP release should be +updated to use the replacement API. To permit evaluation of new ODP +releases in advance of such updating, however, ODP supports the `configure` +option `--enable-deprecated`, which makes the obsolete APIs visible again. + +This feature will be used on a case-by-case basis and documented in the +release notes for each release that introduces replacement API(s). In general +the deprecated forms will not be maintained for more than a single release +cycle. After that they will no longer be present in the API specification and +the replacement forms must be used to compile with that level of the API +specification. + + APIs +A number of new and refined APIs are introduced in crypto, packet parsing, +and queue configuration: + += Crypto Enhancements +The ODP crypto APIs receive several enhancements in this release: + +== New Authentication Algorithms +Additional enumerations added for HMAC-SHA-1 and HMAC-SHA-512 authentication. + +== Deprecated Cipher/Authentication Algorithms +The following cipher/authentication algorithms have been deprecated in favor +of newer replacement algorithms: + +* `ODP_CIPHER_ALG_AES128_CBC` is replaced by `ODP_CIPHER_ALG_AES_CBC` +* `ODP_CIPHER_ALG_AES128_GCM` is replaced by `ODP_CIPHER_ALG_AES_GCM` +* `ODP_AUTH_ALG_MD5_96` is replaced by `ODP_AUTH_ALG_MD5_HMAC` +* `ODP_AUTH_ALG_SHA256_128` is replaced by `ODP_AUTH_ALG_SHA256_HMAC` +* `ODP_AUTH_ALG_AES128_GCM1 is replaced by `ODP_AUTH_ALG_AES_GCM` + +== Deprecated Name for Crypto Parameter struct +`odp_crypto_op_params_t` is deprecated in favor of `odp_crypto_op_param_t` +for consistency with other ODP `param` structs. + +== Digest Length Session Parameter +`odp_crypto_session_param_t` adds the field `auth_digest_len` to permit +specification of the authentication digest length to be used for this +session. The `odp_crypto_auth_capability()` API returns the list of +supported digest lengths. + +== Additional Authentication Data (AAD) +The `odp_crypto_op_param_t` struct adds an optional pointer and length for +AAD information. This allows applications to specify AAD information from +the list of supported lengths provided by `odp_crypto_auth_capability()`. + += Packet Range Data +The former `odp_crypto_data_range_t` type is deprecated and renamed to +`odp_packet_data_range_t` since it can be used to specify ranges for other +than crypto purposes. + += Parser Configuration +Applications may now specify the maximum packet layer of interest. For +example, a router may not care about anything beyond ISO Layer 3 in packets. +This can be used by ODP implementations to control the depth of packet +parsing needed by the application and may allow greater efficiency, +especially in software implementations. + +This is controlled by a new `odp_pktio_parser_layer_t` enum that is +part of the new `odp_pktio_parser_config_t` struct that is added to the +`odp_pktio_config_t` struct used by the `odp_pktio_config()` API. The +supported parser layers are also returned in this struct as part of the +`odp_pktio_capability_t` struct returned by the `odp_pktio_capability()` API. + += Queue Size Parameter +The `odp_queue_capability_t` struct returned by the `odp_queue_capability()` +API is enhanced as follows: +* The `max_queues` field is now defined to return the maximum number of event +queues of any type. +* New sub-structs (`plain` and `sched`) are added that detail the `max_num` of +queues of that type supported as well as the new field `max_size` that +specifies the maximum number of elements that each queue of this type can +store. A value of zero for `max_num` indicates no fixed limit. + +In addition, the `odp_queue_param_t` passed to `odp_queue_create()` now adds +a `size` field to allow applications to specify the minimum number of events +that this queue should be able to store. A value of zero specified requests that +the implementation default limits be used. + +The ODP examples have been updated to show this configuration, for example, +the `l2fwd_simple` example does Layer 2 forwarding and
Re: [lng-odp] [API-NEXT PATCH] api: crypto: correct documentation typos
Reviewed-by: Yi He
On 6 June 2017 at 11:22, Bill Fischofer wrote:
> Correct odp_crypto_auth_capa() to odp_crypto_auth_capability() in
> several places in the spec doxygen.
>
> Signed-off-by: Bill Fischofer
> ---
> include/odp/api/spec/crypto.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/odp/api/spec/crypto.h b/include/odp/api/spec/crypto.h
> index c47d3149..470cba05 100644
> --- a/include/odp/api/spec/crypto.h
> +++ b/include/odp/api/spec/crypto.h
> @@ -296,13 +296,13 @@ typedef struct odp_crypto_session_param_t {
>
> /** Authentication key
> *
> -* Use odp_crypto_auth_capa() for supported key lengths.
> +* Use odp_crypto_auth_capability() for supported key lengths.
> */
> odp_crypto_key_t auth_key;
>
> /** Authentication digest length in bytes
> *
> -* Use odp_crypto_auth_capa() for supported digest lengths.
> +* Use odp_crypto_auth_capability() for supported digest lengths.
> */
> uint32_t auth_digest_len;
>
> @@ -377,7 +377,7 @@ typedef struct odp_crypto_op_param_t {
> /** Pointer to ADD */
> uint8_t *ptr;
>
> - /** AAD length in bytes. Use odp_crypto_auth_capa() for
> + /** AAD length in bytes. Use odp_crypto_auth_capability()
> for
> * supported AAD lengths. */
> uint32_t length;
> } aad;
> --
> 2.11.0
>
>
[lng-odp] [API-NEXT PATCH] api: crypto: correct documentation typos
Correct odp_crypto_auth_capa() to odp_crypto_auth_capability() in
several places in the spec doxygen.
Signed-off-by: Bill Fischofer
---
include/odp/api/spec/crypto.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/odp/api/spec/crypto.h b/include/odp/api/spec/crypto.h
index c47d3149..470cba05 100644
--- a/include/odp/api/spec/crypto.h
+++ b/include/odp/api/spec/crypto.h
@@ -296,13 +296,13 @@ typedef struct odp_crypto_session_param_t {
/** Authentication key
*
-* Use odp_crypto_auth_capa() for supported key lengths.
+* Use odp_crypto_auth_capability() for supported key lengths.
*/
odp_crypto_key_t auth_key;
/** Authentication digest length in bytes
*
-* Use odp_crypto_auth_capa() for supported digest lengths.
+* Use odp_crypto_auth_capability() for supported digest lengths.
*/
uint32_t auth_digest_len;
@@ -377,7 +377,7 @@ typedef struct odp_crypto_op_param_t {
/** Pointer to ADD */
uint8_t *ptr;
- /** AAD length in bytes. Use odp_crypto_auth_capa() for
+ /** AAD length in bytes. Use odp_crypto_auth_capability() for
* supported AAD lengths. */
uint32_t length;
} aad;
--
2.11.0
Re: [lng-odp] [NEXT PATCHv3] changelog: updates for odp v1.15.0.0
Hi, Bill, two minor issues as below. On 6 June 2017 at 00:12, Bill Fischofer wrote: > Signed-off-by: Bill Fischofer > --- > CHANGELOG | 264 ++ > > 1 file changed, 264 insertions(+) > > diff --git a/CHANGELOG b/CHANGELOG > index a550a723..4a7759e2 100644 > --- a/CHANGELOG > +++ b/CHANGELOG > @@ -1,3 +1,267 @@ > +== OpenDataPlane (1.15.0.0) > +=== New Features > +ODP v1.15.0.0 continues the preview of Tiger Moth, introducing new APIs > and > +extensions, as well as numerous bug fixes and functional improvements. > + > + Deprecation Framework > +To permit smoother evolution of the ODP API specification, a deprecation > +framework is introduced to permit controlled deprecation. > + > +When an ODP API or defined struct parameter is deprecated, ODP validation > +tests will be updated to no longer use that API and instead use the > +replacement API. By default, attempts to compile with the older > API/feature > +will fail and applications wishing to move to the new ODP release should > be > +updated to use the replacement API. To permit evaluation of new ODP > +releases in advance of such updating, however, ODP supports the > `configure` > +option `--enable-deprecated`, which makes the obsolete APIs visible again. > + > +This feature will be used on a case-by-case basis and documented in the > +release notes for each release that introduces replacement API(s). In > general > +the deprecated forms will not be maintained for more than a single release > +cycle. After that they will no longer be present in the API specification > and > +the replacement forms must be used to compile with that level of the API > +specification. > + > + APIs > +A number of new and refined APIs are introduced in crypto, packet parsing, > +and queue configuration: > + > += Crypto Enhancements > +The ODP crypto APIs receive several enhancements in this release: > + > +== New Authentication Algorithms > +Additional enumerations added for HMAC-SHA-1 and HMAC-SHA-512 > authentication. > + > +== Deprecated Cipher/Authentication Algorithms > +The following cipher/authentication algorithms have been deprecated in > favor > +of newer replacement algorithms: > + > +* `ODP_CIPHER_ALG_AES128_CBC` is replaced by `ODP_CIPHER_ALG_AES_CBC` > +* `ODP_CIPHER_ALG_AES128_GCM` is replaced by `ODP_CIPHER_ALB_AES_GCM` > `ODP_CIPHER_ALB_AES_GCM` --> `ODP_CIPHER_ALG_AES_GCM`? > +* `ODP_AUTH_ALG_MD5_96` is replaced by `ODP_AUTH_ALG_MD5_HMAC` > +* `ODP_AUTH_ALG_SHA256_128` is replaced by `ODP_AUTH_ALG_SHA256_HMAC` > +* `ODP_AUTH_ALG_AES128_GCM1 is replaced by `ODP_AUTH_ALG_AES_GCM` > + > +== Deprecated Name for Crypto Parameter struct > +`odp_crypto_op_params_t` is deprecated in favor of `odp_crypto_op_param_t` > +for consistency with other ODP `param` structs. > + > +== Digest Length Session Parameter > +`odp_crypto_session_param_t` adds the field `auth_digest_len` to permit > +specification of the authentication digest length to be used for this > +session. The `odp_crypto_auth_capa()` API returns the list of > +supported digest lengths. > `odp_crypto_auth_capa()` API --> `odp_crypto_auth_capability()` API? > + > +== Additional Authentication Data (AAD) > +The `odp_crypto_op_param_t` struct adds an optional pointer and length for > +AAD information. This allows applications to specify AAD information from > +the list of supported lengths provided by `odp_crypto_auth_capability()`. > + > += Packet Range Data > +The former `odp_crypto_data_range_t` type is deprecated and renamed to > +`odp_packet_data_range_t` since it can be used to specify ranges for other > +than crypto purposes. > + > += Parser Configuration > +Applications may now specify the maximum packet layer of interest. For > +example, a router may not care about anything beyond ISO Layer 3 in > packets. > +This can be used by ODP implementations to control the depth of packet > +parsing needed by the application and may allow greater efficiency, > +especially in software implementations. > + > +This is controlled by a new `odp_pktio_parser_layer_t` enum that is > +part of the new `odp_pktio_parser_config_t` struct that is added to the > +`odp_pktio_config_t` struct used by the `odp_pktio_config()` API. The > +supported parser layers are also returned in this struct as part of the > +`odp_pktio_capability_t` struct returned by the `odp_pktio_capability()` > API. > + > += Queue Size Parameter > +The `odp_queue_capability_t` struct returned by the > `odp_queue_capability()` > +API is enhanced as follows: > +* The `max_queues` field is now defined to return the maximum number of > event > +queues of any type. > +* New sub-structs (`plain` and `sched`) are added that detail the > `max_num` of > +queues of that type supported as well as the new field `max_size` that > +specifies the maximum number of elements that each queue of this type can > +store. A value of zero for `max_num` indicates n
Re: [lng-odp] [PATCH v3 0/2] GCC 7 fixes
On 06/05 18:40:02, Bill Fischofer wrote: > After installing a copy of GCC 7, It looks like this patch is an > incomplete fix. With this patch applied older GCC 6.3.0 continues to > work fine, but GCC 7.0.1 generates the following errors: > > Making all in platform/linux-generic > make[1]: Entering directory '/home/bill/linaro/gcc7fix/platform/linux-generic' > CC pktio/ipc.lo > pktio/ipc.c: In function ‘ipc_close’: > pktio/ipc.c:698:33: error: ‘%s’ directive output may be truncated > writing up to 255 bytes into a region of size 32 > [-Werror=format-truncation=] >snprintf(name, sizeof(name), "%s", dev); It looks like ./bootstrap might not have been run after applying the patch?
Re: [lng-odp] [API-NEXT PATCH v2 0/2] IPsec API update
For v2: Reviewed-by: Bill Fischofer On Fri, Jun 2, 2017 at 4:38 AM, Petri Savolainen wrote: > Bill has reviewed v1. > > v2 > * rebase > * removed "api: ipsec: add capability for max packets per result event" from > the set while we decide if result event are changed to packets > * updated max_cls_cos documentation with CLS capability (Bill) > > Petri Savolainen (2): > api: ipsec: refine packet order specification > api: ipsec: add max number of cos capability > > include/odp/api/spec/ipsec.h | 49 > ++-- > 1 file changed, 34 insertions(+), 15 deletions(-) > > -- > 2.11.0 >
Re: [lng-odp] [PATCH v3 0/2] GCC 7 fixes
After installing a copy of GCC 7, It looks like this patch is an incomplete fix. With this patch applied older GCC 6.3.0 continues to work fine, but GCC 7.0.1 generates the following errors: Making all in platform/linux-generic make[1]: Entering directory '/home/bill/linaro/gcc7fix/platform/linux-generic' CC pktio/ipc.lo pktio/ipc.c: In function ‘ipc_close’: pktio/ipc.c:698:33: error: ‘%s’ directive output may be truncated writing up to 255 bytes into a region of size 32 [-Werror=format-truncation=] snprintf(name, sizeof(name), "%s", dev); ^~ In file included from /usr/include/stdio.h:938:0, from /usr/include/openssl/crypto.h:125, from /usr/include/openssl/ui.h:64, from /usr/include/openssl/ui_compat.h:64, from /usr/include/openssl/des_old.h:495, from /usr/include/openssl/des.h:102, from ./include/odp_crypto_internal.h:14, from ./include/odp_packet_internal.h:28, from ./include/odp_classification_datamodel.h:25, from ./include/odp_packet_io_internal.h:23, from ./include/odp_packet_io_ipc_internal.h:8, from pktio/ipc.c:6: /usr/include/x86_64-linux-gnu/bits/stdio2.h:64:10: note: ‘__builtin_snprintf’ output between 1 and 256 bytes into a destination of size 32 return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1, ^~~~ __bos (__s), __fmt, __va_arg_pack ()); ~ cc1: all warnings being treated as errors Makefile:920: recipe for target 'pktio/ipc.lo' failed make[1]: *** [pktio/ipc.lo] Error 1 CC pktio/pktio_common.lo CC pktio/loop.lo CC pktio/netmap.lo CC pktio/dpdk.lo CC pktio/socket.lo CC pktio/socket_mmap.lo CC pktio/sysfs.lo pktio/sysfs.c: In function ‘sysfs_stats’: pktio/sysfs.c:50:33: error: ‘%s’ directive writing up to 255 bytes into a region of size 241 [-Werror=format-overflow=] sprintf(fname, "/sys/class/net/%s/statistics/rx_bytes", dev); ^~ In file included from /usr/include/stdio.h:938:0, from /usr/include/openssl/crypto.h:125, from /usr/include/openssl/ui.h:64, from /usr/include/openssl/ui_compat.h:64, from /usr/include/openssl/des_old.h:495, from /usr/include/openssl/des.h:102, from ./include/odp_crypto_internal.h:14, from ./include/odp_packet_internal.h:28, from ./include/odp_classification_datamodel.h:25, from ./include/odp_packet_io_internal.h:23, from pktio/sysfs.c:8: /usr/include/x86_64-linux-gnu/bits/stdio2.h:33:10: note: ‘__builtin___sprintf_chk’ output between 36 and 291 bytes into a destination of size 256 return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, ^~ __bos (__s), __fmt, __va_arg_pack ()); ~ pktio/sysfs.c:53:33: error: ‘%s’ directive writing up to 255 bytes into a region of size 241 [-Werror=format-overflow=] sprintf(fname, "/sys/class/net/%s/statistics/rx_packets", dev); ^~ In file included from /usr/include/stdio.h:938:0, from /usr/include/openssl/crypto.h:125, from /usr/include/openssl/ui.h:64, from /usr/include/openssl/ui_compat.h:64, from /usr/include/openssl/des_old.h:495, from /usr/include/openssl/des.h:102, from ./include/odp_crypto_internal.h:14, from ./include/odp_packet_internal.h:28, from ./include/odp_classification_datamodel.h:25, from ./include/odp_packet_io_internal.h:23, from pktio/sysfs.c:8: /usr/include/x86_64-linux-gnu/bits/stdio2.h:33:10: note: ‘__builtin___sprintf_chk’ output between 38 and 293 bytes into a destination of size 256 return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, ^~ __bos (__s), __fmt, __va_arg_pack ()); ~ pktio/sysfs.c:56:33: error: ‘%s’ directive writing up to 255 bytes into a region of size 241 [-Werror=format-overflow=] sprintf(fname, "/sys/class/net/%s/statistics/rx_droppped", dev); ^~ In file included from /usr/include/stdio.h:938:0, from /usr/include/openssl/crypto.h:125, from /usr/include/openssl/ui.h:64, from /usr/include/openssl/ui_compat.h:64, from /usr/include/openssl/des_old.h:495, from /usr/include/openssl/des.h:102, from ./include/
[lng-odp] [PATCH v3 1/2] build: GCC 7 fixes
The GCC 7 series introduces changes that expose ODP compilation
issues. These include case statement fall through warnings, and
stricter checks on potential string overflows and other semantic
analysis.
Fixes: https://bugs.linaro.org/show_bug.cgi?id=3027
Signed-off-by: Brian Brooks
Reviewed-by: Ola Liljedahl
Reviewed-by: Honnappa Nagarahalli
---
DEPENDENCIES | 5 ++--
configure.ac | 8 +++
platform/linux-generic/m4/configure.m4 | 44 ++
3 files changed, 55 insertions(+), 2 deletions(-)
diff --git a/DEPENDENCIES b/DEPENDENCIES
index a194cad1..7bcbd5eb 100644
--- a/DEPENDENCIES
+++ b/DEPENDENCIES
@@ -8,13 +8,14 @@ Prerequisites for building the OpenDataPlane (ODP) API
automake
autoconf
+ autoconf-archive
libtool
On Debian/Ubuntu systems:
- $ sudo apt-get install automake autoconf libtool
+ $ sudo apt-get install automake autoconf autoconf-archive libtool
On CentOS/RedHat/Fedora systems:
- $ sudo yum install automake autoconf libtool
+ $ sudo yum install automake autoconf autoconf-archive libtool
3. Required libraries
diff --git a/configure.ac b/configure.ac
index 7569ebe0..e61d94ca 100644
--- a/configure.ac
+++ b/configure.ac
@@ -300,6 +300,14 @@ ODP_CFLAGS="$ODP_CFLAGS -Wmissing-declarations
-Wold-style-definition -Wpointer-
ODP_CFLAGS="$ODP_CFLAGS -Wcast-align -Wnested-externs -Wcast-qual
-Wformat-nonliteral"
ODP_CFLAGS="$ODP_CFLAGS -Wformat-security -Wundef -Wwrite-strings"
ODP_CFLAGS="$ODP_CFLAGS -std=c99"
+
+AX_CHECK_COMPILE_FLAG([-Wimplicit-fallthrough=0],
+ [ODP_CFLAGS="$ODP_CFLAGS -Wimplicit-fallthrough=0"])
+AX_CHECK_COMPILE_FLAG([-Wformat-truncation=0],
+ [ODP_CFLAGS="$ODP_CFLAGS -Wformat-truncation=0"])
+AX_CHECK_COMPILE_FLAG([-Wformat-overflow=0],
+ [ODP_CFLAGS="$ODP_CFLAGS -Wformat-overflow=0"])
+
# Extra flags for example to suppress certain warning types
ODP_CFLAGS="$ODP_CFLAGS $ODP_CFLAGS_EXTRA"
diff --git a/platform/linux-generic/m4/configure.m4
b/platform/linux-generic/m4/configure.m4
index a2a25408..be04da8a 100644
--- a/platform/linux-generic/m4/configure.m4
+++ b/platform/linux-generic/m4/configure.m4
@@ -28,6 +28,50 @@ AC_LINK_IFELSE(
echo "Use newer version. For gcc > 4.7.0"
exit -1)
+dnl Check whether -latomic is needed
+use_libatomic=no
+
+AC_MSG_CHECKING(whether -latomic is needed for 64-bit atomic built-ins)
+AC_LINK_IFELSE(
+ [AC_LANG_SOURCE([[
+static int loc;
+int main(void)
+{
+int prev = __atomic_exchange_n(&loc, 7, __ATOMIC_RELAXED);
+return 0;
+}
+]])],
+ [AC_MSG_RESULT(no)],
+ [AC_MSG_RESULT(yes)
+ AC_CHECK_LIB(
+ [atomic], [__atomic_exchange_8],
+ [use_libatomic=yes],
+ [AC_MSG_FAILURE([__atomic_exchange_8 is not available])])
+ ])
+
+AC_MSG_CHECKING(whether -latomic is needed for 128-bit atomic built-ins)
+AC_LINK_IFELSE(
+ [AC_LANG_SOURCE([[
+static __int128 loc;
+int main(void)
+{
+__int128 prev;
+prev = __atomic_exchange_n(&loc, 7, __ATOMIC_RELAXED);
+return 0;
+}
+]])],
+ [AC_MSG_RESULT(no)],
+ [AC_MSG_RESULT(yes)
+ AC_CHECK_LIB(
+ [atomic], [__atomic_exchange_16],
+ [use_libatomic=yes],
+ [AC_MSG_FAILURE([cannot detect support for 128-bit atomics])])
+ ])
+
+if test "x$use_libatomic" = "xyes"; then
+ AM_LDFLAGS="$AM_LDFLAGS -latomic"
+fi
+
m4_include([platform/linux-generic/m4/odp_pthread.m4])
m4_include([platform/linux-generic/m4/odp_openssl.m4])
m4_include([platform/linux-generic/m4/odp_pcap.m4])
--
2.13.0
[lng-odp] [PATCH v3 0/2] GCC 7 fixes
The GCC 7 series introduces changes that expose ODP compilation issues. These include case statement fall through warnings, and stricter checks on potential string overflows and other semantic analysis. Fixes: https://bugs.linaro.org/show_bug.cgi?id=3027 Brian Brooks (2): build: GCC 7 fixes pktio: GCC 7 fixes DEPENDENCIES | 5 +-- configure.ac | 8 + platform/linux-generic/m4/configure.m4| 44 +++ test/common_plat/validation/api/pktio/pktio.c | 4 ++- 4 files changed, 58 insertions(+), 3 deletions(-) -- v3: - Split into multiple patches files (Maxim) - Disable warnings in favor of patching right now (Dmitry) - Improve libatomic detection in autoconf (Dmitry) - Add autoconf-arch to DEPENDENCIES file v2: - Add Bug id to commit message (Bill) 2.13.0
[lng-odp] [PATCH v3 2/2] pktio: GCC 7 fixes
The GCC 7 series introduces changes that expose ODP compilation
issues. These include case statement fall through warnings, and
stricter checks on potential string overflows and other semantic
analysis.
Fixes: https://bugs.linaro.org/show_bug.cgi?id=3027
Signed-off-by: Brian Brooks
---
test/common_plat/validation/api/pktio/pktio.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/test/common_plat/validation/api/pktio/pktio.c
b/test/common_plat/validation/api/pktio/pktio.c
index 11fe974f..4d8d2cc7 100644
--- a/test/common_plat/validation/api/pktio/pktio.c
+++ b/test/common_plat/validation/api/pktio/pktio.c
@@ -1429,7 +1429,9 @@ int pktio_check_statistics_counters(void)
void pktio_test_statistics_counters(void)
{
odp_pktio_t pktio_rx, pktio_tx;
- odp_pktio_t pktio[MAX_NUM_IFACES];
+ odp_pktio_t pktio[MAX_NUM_IFACES] = {
+ ODP_PKTIO_INVALID, ODP_PKTIO_INVALID
+ };
odp_packet_t pkt;
odp_packet_t tx_pkt[1000];
uint32_t pkt_seq[1000];
--
2.13.0
Re: [lng-odp] [PATCH] Fixes for GCC 7
On 06/02 20:34:21, Dmitry Eremin-Solenikov wrote: > Or just > > AC_LINK_IFELSE([AC_LANG_CALL([], [your_atomic_func])], [ATOMIC_LIBS=""], >[AC_CHECK_LIB([atomic], [your_atomic_func], [ATOMIC_LIBS="-latomic"], > [AC_MSG_FAILURE([your_atomic_func is not available])])]) > AC_SUBST([ATOMIC_LIBS]) This appears to be it except AC_LANG_SOURCE needs to be used instead of AC_LANG_CALL due to type issues (e.g. autoconf assumes the declaration to be: char __atomic_exchange_16() which fails).
Re: [lng-odp] [PATCH] Fixes for GCC 7
On 06/02 20:09:54, Dmitry Eremin-Solenikov wrote:
> On 02.06.2017 18:34, Brian Brooks wrote:
> > On 06/02 10:39:18, Dmitry Eremin-Solenikov wrote:
> >> On 01.06.2017 22:05, Brian Brooks wrote:
> >>> Signed-off-by: Brian Brooks
> >>> Reviewed-by: Ola Liljedahl
> >>> Reviewed-by: Honnappa Nagarahalli
> >>> ---
> >>> configure.ac | 5 +
> >>> platform/linux-generic/m4/configure.m4| 4
> >>> platform/linux-generic/pktio/ipc.c| 6 --
> >>> platform/linux-generic/pktio/sysfs.c | 2 +-
> >>> test/common_plat/validation/api/pktio/pktio.c | 4 +++-
> >>> 5 files changed, 17 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/configure.ac b/configure.ac
> >>> index 7569ebe0..5eabe4d4 100644
> >>> --- a/configure.ac
> >>> +++ b/configure.ac
> >>> @@ -300,6 +300,11 @@ ODP_CFLAGS="$ODP_CFLAGS -Wmissing-declarations
> >>> -Wold-style-definition -Wpointer-
> >>> ODP_CFLAGS="$ODP_CFLAGS -Wcast-align -Wnested-externs -Wcast-qual
> >>> -Wformat-nonliteral"
> >>> ODP_CFLAGS="$ODP_CFLAGS -Wformat-security -Wundef -Wwrite-strings"
> >>> ODP_CFLAGS="$ODP_CFLAGS -std=c99"
> >>> +
> >>> +if test "${CC}" == "gcc" -a ${CC_VERSION_MAJOR} -ge 7; then
> >>> + ODP_CFLAGS="$ODP_CFLAGS -Wimplicit-fallthrough=0"
> >>> +fi
> >>> +
> >>
> >> Shouldn't Wimplicit-fallthrough=2 be enough? Where are you hitting the
> >> warning?
> >
> > Not every fallthrough is commented.
> >
> > Please read the manual if you would like to know more:
> > https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Warning-Options.html#Warning-Options
>
> So, it would be better to add necessary comments in my opinion.
> The warning is useful.
Agree warnings are good, but disabling the warning will keep the build sane
for those who are using GCC 7 now. When more people upgrade, the additional
warnings can be turned on and fixed in bulk.
> >>> # Extra flags for example to suppress certain warning types
> >>> ODP_CFLAGS="$ODP_CFLAGS $ODP_CFLAGS_EXTRA"
> >>>
> >>> diff --git a/platform/linux-generic/m4/configure.m4
> >>> b/platform/linux-generic/m4/configure.m4
> >>> index a2a25408..3e2978b5 100644
> >>> --- a/platform/linux-generic/m4/configure.m4
> >>> +++ b/platform/linux-generic/m4/configure.m4
> >>> @@ -28,6 +28,10 @@ AC_LINK_IFELSE(
> >>> echo "Use newer version. For gcc > 4.7.0"
> >>> exit -1)
> >>>
> >>> +if test "${CC}" == "gcc" -a ${CC_VERSION_MAJOR} -ge 7; then
> >>> + AM_LDFLAGS="$AM_LDFLAGS -latomic"
> >>> +fi
> >>> +
> >>
> >> This should be replaced with proper AC_CHECK_LIB or AC_SEARCH_LIBS
> >
> > I don't think so. The link to libatomic is needed based on the compiler
> > version, not based on whether a program compiles with -latomic or not
> > which is AC_CHECK_LIB behavior. If you disagree, please show me how it
> > can be done.
> >
> > This is also a very simple (3 line) solution.
>
> Simple solution:
>
> AC_SEARCH_LIBS([your_atomic_func], [atomic])
>
> Cleaner solution:
>
> AC_LINK_IFELSE([AC_LANG_CALL([], [your_atomic_func])], [ATOMIC_LIBS=""],
> [OLDLIBS=$LIBS
> LIBS="$LIBS -latomic"
> AC_LINK_IFELSE([AC_LANG_CALL([], [your_atomic_func])],
> [ATOMIC_LIBS="-latomic"],
> [AC_MSG_FAILURE([your_atomic_func is not available])])
> LIBS=$OLDLIBS])
> AC_SUBST([ATOMIC_LIBS])
>
> Then you can use $(ATOMIC_LIBS) when you need to use your_atomic_function().
>
>
> >>> m4_include([platform/linux-generic/m4/odp_pthread.m4])
> >>> m4_include([platform/linux-generic/m4/odp_openssl.m4])
> >>> m4_include([platform/linux-generic/m4/odp_pcap.m4])
> >>> diff --git a/platform/linux-generic/pktio/ipc.c
> >>> b/platform/linux-generic/pktio/ipc.c
> >>> index 06175e5a..29c3a546 100644
> >>> --- a/platform/linux-generic/pktio/ipc.c
> >>> +++ b/platform/linux-generic/pktio/ipc.c
> >>> @@ -694,8 +694,10 @@ static int ipc_close(pktio_entry_t *pktio_entry)
> >>>
> >>> if (sscanf(dev, "ipc:%d:%s", &pid, tail) == 2)
> >>> snprintf(name, sizeof(name), "ipc:%s", tail);
> >>> - else
> >>> - snprintf(name, sizeof(name), "%s", dev);
> >>> + else {
> >>> + strncpy(name, dev, sizeof(name));
> >>> + name[sizeof(name) - 1] = '\0';
> >>> + }
> >>
> >> Why?
> >
> > New -Wformat-truncation=level behavior. Please read the manual if you'd like
> > to know more.
>
> I'd suggest instead to disable -Wformat-truncation.
Agree, if it is possible.
Re: [lng-odp] [PATCH] Fixes for GCC 7
On 06/02 23:27:08, Maxim Uvarov wrote: > On 06/02/17 18:36, Brian Brooks wrote: > > On 06/02 15:07:48, Maxim Uvarov wrote: > >> I think this patch has to be spit on several patches. Having patch which > >> correct unrelated things is strange and make it hard to merge/cherry-pick. > > > > They are all related to things that break the build with GCC 7. It's > > unnecessary and extra complexity to split it up into more than one patch. > > The single patch is small and easily reviewable anyway. > > > > Idea here is the following. Different odp implementations can inherit > specific parts of mainline ODP to their code. For example changes to > configure.ac might be sufficient for odp-dpdk and change to fix pktio > name is not. Other platform developers prefer to take entire commit > from linux-generic with git cherry-pick command. Aha, so split into build related changes and source related changes? > Maxim. > > > > > >> > >> Maxim. >
Re: [lng-odp] [RFC] api: pool: add threshold limit to the pool
Regards,
Bala
On 5 June 2017 at 21:52, Bill Fischofer wrote:
> On Mon, Jun 5, 2017 at 8:24 AM, Bala Manoharan
> wrote:
>> Regards,
>> Bala
>>
>>
>> On 5 June 2017 at 18:24, Bill Fischofer wrote:
>>> On Mon, Jun 5, 2017 at 7:32 AM, Stanislaw Kardach wrote:
Best Regards,
Stanislaw Kardach
On 06/05/2017 02:27 PM, Balasubramanian Manoharan wrote:
> Adds threshold limit of the pool to the pool parameters.
> This threshold limit is a percentage of total size of the pool.
>
> Signed-off-by: Balasubramanian Manoharan
> ---
> include/odp/api/spec/pool.h | 32
> 1 file changed, 32 insertions(+)
>
> diff --git a/include/odp/api/spec/pool.h b/include/odp/api/spec/pool.h
> index 6fc5b6b..1c1ebe4 100644
> --- a/include/odp/api/spec/pool.h
> +++ b/include/odp/api/spec/pool.h
> @@ -20,6 +20,7 @@ extern "C" {
> #endif
>
> #include
> +#include
>
> /** @defgroup odp_pool ODP POOL
> * Operations on a pool.
> @@ -127,6 +128,9 @@ typedef struct odp_pool_capability_t {
>* The value of zero means that limited only by the
> available
>* memory size for the pool. */
> uint32_t max_uarea_size;
> +
> + /** Pool Threshold limit support */
> + odp_support_t pool_threshold_limit;
> } pkt;
>
> /** Timeout pool capabilities */
> @@ -214,6 +218,17 @@ typedef struct odp_pool_param_t {
> defined by pool capability pkt.max_uarea_size.
> Specify as 0 if no user area is needed. */
> uint32_t uarea_size;
> +
> + /** Pool threshold limit in percentage
> + *
> + * This value denotes the threshold limit of the
> pool in
> + * percentage of the total size of the pool and is
> used
> + * to configure the Random Early Discard (RED).
> + * When the number of packets in the pool is greater
> + * than this value RED is initiated in the pool and
> + * further incoming packets to the pool are dropped
> in
> + * a random sequence. */
> + uint8_t threshold_limit;
Is threshold limit "a percentage of total size of the pool" (hence I
guess 0-100) or rather an absolute value that triggers RED?
>>>
>>> Do we want to tie this specifically to RED or try to make things more
>>> general? There are many types of flow/congestion control algorithms
>>> that can be used so perhaps that should be better parameterized? Also,
>>> when specifying thresholds it's customary to set high and low
>>> watermarks to provide hysteresis. Some algorithms also need more than
>>> one data point to control the curves, so again this suggests that we
>>> need additional parameterization for this.
>>
>> The idea is to have a configuration value for enabling or disabling
>> Random Early Discard in the packet ingress which could be configured
>> either in the queue or in pool depending on the implementation. I
>> actually thought about having a higher /lower watermark but went
>> against this since the logic I have followed in this proposal is to
>> have a mechanism to start or stop the RED, IMO a single threshold
>> value is sufficient and RED gets initiated when packet is greater than
>> the threshold and is disabled when the packet limit on the pool is
>> lesser than this threshold.
>
> A single value may work for basic RED, but if you want to support
> other options like PFC then you need more than a single value or else
> you wind up "stuttering" around the single value when utilization is
> very close to it. That's because PFC doesn't just do something with a
> packet--it actively transmits pause frames.
I have only targeted basic RED in this proposal, which is common
across all platforms and it would be great to incorporate it to the
ODP ASAP.
If some other platforms comes with support for PFC at the hardware
level then we can add those additional features.
IMO we could keep this proposal simple so it is easier for upstreaming.
>
>>
>>>
> } pkt;
>
> /** Parameters for timeout pools */
> @@ -329,6 +344,23 @@ uint64_t odp_pool_to_u64(odp_pool_t hdl);
> void odp_pool_param_init(odp_pool_param_t *param);
>
> /**
> + * Set threshold limit of the pool
> + *
> + * Set the threshold limit of the pool as a percentage of the total
> + * size of the pool. This value is used to configure Random Early
> Discard(RED)
> + * parameters of the pool and any incoming packets to the pool after
> reaching
> + * this threshold is dropped in a random sequence.
> + *
Re: [lng-odp] [RFC] api: pool: add threshold limit to the pool
On Mon, Jun 5, 2017 at 8:24 AM, Bala Manoharan
wrote:
> Regards,
> Bala
>
>
> On 5 June 2017 at 18:24, Bill Fischofer wrote:
>> On Mon, Jun 5, 2017 at 7:32 AM, Stanislaw Kardach wrote:
>>>
>>>
>>> Best Regards,
>>> Stanislaw Kardach
>>>
>>> On 06/05/2017 02:27 PM, Balasubramanian Manoharan wrote:
Adds threshold limit of the pool to the pool parameters.
This threshold limit is a percentage of total size of the pool.
Signed-off-by: Balasubramanian Manoharan
---
include/odp/api/spec/pool.h | 32
1 file changed, 32 insertions(+)
diff --git a/include/odp/api/spec/pool.h b/include/odp/api/spec/pool.h
index 6fc5b6b..1c1ebe4 100644
--- a/include/odp/api/spec/pool.h
+++ b/include/odp/api/spec/pool.h
@@ -20,6 +20,7 @@ extern "C" {
#endif
#include
+#include
/** @defgroup odp_pool ODP POOL
* Operations on a pool.
@@ -127,6 +128,9 @@ typedef struct odp_pool_capability_t {
* The value of zero means that limited only by the available
* memory size for the pool. */
uint32_t max_uarea_size;
+
+ /** Pool Threshold limit support */
+ odp_support_t pool_threshold_limit;
} pkt;
/** Timeout pool capabilities */
@@ -214,6 +218,17 @@ typedef struct odp_pool_param_t {
defined by pool capability pkt.max_uarea_size.
Specify as 0 if no user area is needed. */
uint32_t uarea_size;
+
+ /** Pool threshold limit in percentage
+ *
+ * This value denotes the threshold limit of the
pool in
+ * percentage of the total size of the pool and is
used
+ * to configure the Random Early Discard (RED).
+ * When the number of packets in the pool is greater
+ * than this value RED is initiated in the pool and
+ * further incoming packets to the pool are dropped
in
+ * a random sequence. */
+ uint8_t threshold_limit;
>>> Is threshold limit "a percentage of total size of the pool" (hence I
>>> guess 0-100) or rather an absolute value that triggers RED?
>>
>> Do we want to tie this specifically to RED or try to make things more
>> general? There are many types of flow/congestion control algorithms
>> that can be used so perhaps that should be better parameterized? Also,
>> when specifying thresholds it's customary to set high and low
>> watermarks to provide hysteresis. Some algorithms also need more than
>> one data point to control the curves, so again this suggests that we
>> need additional parameterization for this.
>
> The idea is to have a configuration value for enabling or disabling
> Random Early Discard in the packet ingress which could be configured
> either in the queue or in pool depending on the implementation. I
> actually thought about having a higher /lower watermark but went
> against this since the logic I have followed in this proposal is to
> have a mechanism to start or stop the RED, IMO a single threshold
> value is sufficient and RED gets initiated when packet is greater than
> the threshold and is disabled when the packet limit on the pool is
> lesser than this threshold.
A single value may work for basic RED, but if you want to support
other options like PFC then you need more than a single value or else
you wind up "stuttering" around the single value when utilization is
very close to it. That's because PFC doesn't just do something with a
packet--it actively transmits pause frames.
>
>>
>>>
} pkt;
/** Parameters for timeout pools */
@@ -329,6 +344,23 @@ uint64_t odp_pool_to_u64(odp_pool_t hdl);
void odp_pool_param_init(odp_pool_param_t *param);
/**
+ * Set threshold limit of the pool
+ *
+ * Set the threshold limit of the pool as a percentage of the total
+ * size of the pool. This value is used to configure Random Early
Discard(RED)
+ * parameters of the pool and any incoming packets to the pool after
reaching
+ * this threshold is dropped in a random sequence.
+ *
+ * @param pool Pool handle
+ * @param threshold_limitThreshold limit of the pool.
+ *
+ * @retval 0 on success
+ * @retval -1 on failure
+ */
+
+int odp_pool_threshold_limit(odp_pool_t pool, uint8_t threshold_limit);
+
+/**
* @}
*/
Re: [lng-odp] [NEXT PATCH] changelog: updates for odp v1.15.0.0
On Mon, Jun 5, 2017 at 8:12 AM, Dmitry Eremin-Solenikov wrote: > On 04.06.2017 22:18, Bill Fischofer wrote: >> Signed-off-by: Bill Fischofer >> --- >> CHANGELOG | 266 >> ++ >> 1 file changed, 266 insertions(+) >> >> diff --git a/CHANGELOG b/CHANGELOG >> index a550a723..bdb5ca49 100644 > > [skipped] > >> += Crypto Enhancements >> +The ODP crypto APIs receive several enhancements in this release: >> + >> +== New Authentication Algorithms >> +Additional enumerations added for HMAC-SHA-1 and HMAC-SHA-256 >> authentication. >> +Note that These are not yet implemented in `odp-linux` so >> +`odp_crypto_capabilities()` returns zeros for these new authentication >> types. > > Sorry, Bill. This paragraph should mention HMAC-SHA-512 instead of -256. Thanks. Fixed in v3. > > > > -- > With best wishes > Dmitry
[lng-odp] [NEXT PATCHv3] changelog: updates for odp v1.15.0.0
Signed-off-by: Bill Fischofer --- CHANGELOG | 264 ++ 1 file changed, 264 insertions(+) diff --git a/CHANGELOG b/CHANGELOG index a550a723..4a7759e2 100644 --- a/CHANGELOG +++ b/CHANGELOG @@ -1,3 +1,267 @@ +== OpenDataPlane (1.15.0.0) +=== New Features +ODP v1.15.0.0 continues the preview of Tiger Moth, introducing new APIs and +extensions, as well as numerous bug fixes and functional improvements. + + Deprecation Framework +To permit smoother evolution of the ODP API specification, a deprecation +framework is introduced to permit controlled deprecation. + +When an ODP API or defined struct parameter is deprecated, ODP validation +tests will be updated to no longer use that API and instead use the +replacement API. By default, attempts to compile with the older API/feature +will fail and applications wishing to move to the new ODP release should be +updated to use the replacement API. To permit evaluation of new ODP +releases in advance of such updating, however, ODP supports the `configure` +option `--enable-deprecated`, which makes the obsolete APIs visible again. + +This feature will be used on a case-by-case basis and documented in the +release notes for each release that introduces replacement API(s). In general +the deprecated forms will not be maintained for more than a single release +cycle. After that they will no longer be present in the API specification and +the replacement forms must be used to compile with that level of the API +specification. + + APIs +A number of new and refined APIs are introduced in crypto, packet parsing, +and queue configuration: + += Crypto Enhancements +The ODP crypto APIs receive several enhancements in this release: + +== New Authentication Algorithms +Additional enumerations added for HMAC-SHA-1 and HMAC-SHA-512 authentication. + +== Deprecated Cipher/Authentication Algorithms +The following cipher/authentication algorithms have been deprecated in favor +of newer replacement algorithms: + +* `ODP_CIPHER_ALG_AES128_CBC` is replaced by `ODP_CIPHER_ALG_AES_CBC` +* `ODP_CIPHER_ALG_AES128_GCM` is replaced by `ODP_CIPHER_ALB_AES_GCM` +* `ODP_AUTH_ALG_MD5_96` is replaced by `ODP_AUTH_ALG_MD5_HMAC` +* `ODP_AUTH_ALG_SHA256_128` is replaced by `ODP_AUTH_ALG_SHA256_HMAC` +* `ODP_AUTH_ALG_AES128_GCM1 is replaced by `ODP_AUTH_ALG_AES_GCM` + +== Deprecated Name for Crypto Parameter struct +`odp_crypto_op_params_t` is deprecated in favor of `odp_crypto_op_param_t` +for consistency with other ODP `param` structs. + +== Digest Length Session Parameter +`odp_crypto_session_param_t` adds the field `auth_digest_len` to permit +specification of the authentication digest length to be used for this +session. The `odp_crypto_auth_capa()` API returns the list of +supported digest lengths. + +== Additional Authentication Data (AAD) +The `odp_crypto_op_param_t` struct adds an optional pointer and length for +AAD information. This allows applications to specify AAD information from +the list of supported lengths provided by `odp_crypto_auth_capability()`. + += Packet Range Data +The former `odp_crypto_data_range_t` type is deprecated and renamed to +`odp_packet_data_range_t` since it can be used to specify ranges for other +than crypto purposes. + += Parser Configuration +Applications may now specify the maximum packet layer of interest. For +example, a router may not care about anything beyond ISO Layer 3 in packets. +This can be used by ODP implementations to control the depth of packet +parsing needed by the application and may allow greater efficiency, +especially in software implementations. + +This is controlled by a new `odp_pktio_parser_layer_t` enum that is +part of the new `odp_pktio_parser_config_t` struct that is added to the +`odp_pktio_config_t` struct used by the `odp_pktio_config()` API. The +supported parser layers are also returned in this struct as part of the +`odp_pktio_capability_t` struct returned by the `odp_pktio_capability()` API. + += Queue Size Parameter +The `odp_queue_capability_t` struct returned by the `odp_queue_capability()` +API is enhanced as follows: +* The `max_queues` field is now defined to return the maximum number of event +queues of any type. +* New sub-structs (`plain` and `sched`) are added that detail the `max_num` of +queues of that type supported as well as the new field `max_size` that +specifies the maximum number of elements that each queue of this type can +store. A value of zero for `max_num` indicates no fixed limit. + +In addition, the `odp_queue_param_t` passed to `odp_queue_create()` now adds +a `size` field to allow applications to specify the minimum number of events +that this queue should be able to store. A value of zero specified requests that +the implementation default limits be used. + +The ODP examples have been updated to show this configuration, for example, +the `l2fwd_simple` example does Layer 2 forwarding and hence
Re: [lng-odp] [RFC] api: pool: add threshold limit to the pool
Regards,
Bala
On 5 June 2017 at 18:24, Bill Fischofer wrote:
> On Mon, Jun 5, 2017 at 7:32 AM, Stanislaw Kardach wrote:
>>
>>
>> Best Regards,
>> Stanislaw Kardach
>>
>> On 06/05/2017 02:27 PM, Balasubramanian Manoharan wrote:
>>> Adds threshold limit of the pool to the pool parameters.
>>> This threshold limit is a percentage of total size of the pool.
>>>
>>> Signed-off-by: Balasubramanian Manoharan
>>> ---
>>> include/odp/api/spec/pool.h | 32
>>> 1 file changed, 32 insertions(+)
>>>
>>> diff --git a/include/odp/api/spec/pool.h b/include/odp/api/spec/pool.h
>>> index 6fc5b6b..1c1ebe4 100644
>>> --- a/include/odp/api/spec/pool.h
>>> +++ b/include/odp/api/spec/pool.h
>>> @@ -20,6 +20,7 @@ extern "C" {
>>> #endif
>>>
>>> #include
>>> +#include
>>>
>>> /** @defgroup odp_pool ODP POOL
>>> * Operations on a pool.
>>> @@ -127,6 +128,9 @@ typedef struct odp_pool_capability_t {
>>>* The value of zero means that limited only by the available
>>>* memory size for the pool. */
>>> uint32_t max_uarea_size;
>>> +
>>> + /** Pool Threshold limit support */
>>> + odp_support_t pool_threshold_limit;
>>> } pkt;
>>>
>>> /** Timeout pool capabilities */
>>> @@ -214,6 +218,17 @@ typedef struct odp_pool_param_t {
>>> defined by pool capability pkt.max_uarea_size.
>>> Specify as 0 if no user area is needed. */
>>> uint32_t uarea_size;
>>> +
>>> + /** Pool threshold limit in percentage
>>> + *
>>> + * This value denotes the threshold limit of the pool
>>> in
>>> + * percentage of the total size of the pool and is
>>> used
>>> + * to configure the Random Early Discard (RED).
>>> + * When the number of packets in the pool is greater
>>> + * than this value RED is initiated in the pool and
>>> + * further incoming packets to the pool are dropped in
>>> + * a random sequence. */
>>> + uint8_t threshold_limit;
>> Is threshold limit "a percentage of total size of the pool" (hence I
>> guess 0-100) or rather an absolute value that triggers RED?
>
> Do we want to tie this specifically to RED or try to make things more
> general? There are many types of flow/congestion control algorithms
> that can be used so perhaps that should be better parameterized? Also,
> when specifying thresholds it's customary to set high and low
> watermarks to provide hysteresis. Some algorithms also need more than
> one data point to control the curves, so again this suggests that we
> need additional parameterization for this.
The idea is to have a configuration value for enabling or disabling
Random Early Discard in the packet ingress which could be configured
either in the queue or in pool depending on the implementation. I
actually thought about having a higher /lower watermark but went
against this since the logic I have followed in this proposal is to
have a mechanism to start or stop the RED, IMO a single threshold
value is sufficient and RED gets initiated when packet is greater than
the threshold and is disabled when the packet limit on the pool is
lesser than this threshold.
>
>>
>>> } pkt;
>>>
>>> /** Parameters for timeout pools */
>>> @@ -329,6 +344,23 @@ uint64_t odp_pool_to_u64(odp_pool_t hdl);
>>> void odp_pool_param_init(odp_pool_param_t *param);
>>>
>>> /**
>>> + * Set threshold limit of the pool
>>> + *
>>> + * Set the threshold limit of the pool as a percentage of the total
>>> + * size of the pool. This value is used to configure Random Early
>>> Discard(RED)
>>> + * parameters of the pool and any incoming packets to the pool after
>>> reaching
>>> + * this threshold is dropped in a random sequence.
>>> + *
>>> + * @param pool Pool handle
>>> + * @param threshold_limitThreshold limit of the pool.
>>> + *
>>> + * @retval 0 on success
>>> + * @retval -1 on failure
>>> + */
>>> +
>>> +int odp_pool_threshold_limit(odp_pool_t pool, uint8_t threshold_limit);
>>> +
>>> +/**
>>> * @}
>>> */
>>>
>>>
Re: [lng-odp] [PATCH v1 0/9] Rework the way ODP links with other libraries
> On 5 Jun 2017, at 16:11, Dmitry Eremin-Solenikov > wrote: > > $ nm test/common_plat/performance/odp_l2fwd | grep vdrv > 001e7fd0 T rte_eal_vdrv_register > 001e8000 T rte_eal_vdrv_unregister > 0001bfe0 t vdrvinitfn_cryptodev_null_pmd_drv > 0001bcf0 t vdrvinitfn_pmd_af_packet_drv > 0001bd40 t vdrvinitfn_pmd_bond_drv > 0001bfb0 t vdrvinitfn_pmd_null_drv > 0001c010 t vdrvinitfn_pmd_pcap_drv > 0001c080 t vdrvinitfn_pmd_ring_drv > 0001c0d0 t vdrvinitfn_pmd_tap_drv > 0001c100 t vdrvinitfn_pmd_vhost_drv > 0001c150 t vdrvinitfn_virtio_user_driver For me: $ ./configure --enable-test-perf --enable-test-vald --enable-test-cpp --enable-test-example --enable-test-helper --enable-helper-linux --with-cunit-path=/home/NNN/CUnitHome --with-netmap-path=/home/NNN/dev/netmap.git --with-dpdk-path=/home/NNN/dev/dpdk.git/x86_64-native-linuxapp-gcc --prefix=/home/NNN/odp_install $ nm test/common_plat/performance/odp_l2fwd | grep vdrv 0044dc30 T rte_eal_vdrv_register 0044dc60 T rte_eal_vdrv_unregister Before the patch set: $ nm test/common_plat/performance/odp_l2fwd | grep vdrv 005b36e0 T rte_eal_vdrv_register 005b3710 T rte_eal_vdrv_unregister 0040a8b0 t vdrvinitfn_cryptodev_null_pmd_drv 0040a8e0 t vdrvinitfn_cryptodev_openssl_pmd_drv 0040a5c0 t vdrvinitfn_pmd_af_packet_drv 0040a610 t vdrvinitfn_pmd_bond_drv 0040a880 t vdrvinitfn_pmd_null_drv 0040a910 t vdrvinitfn_pmd_pcap_drv 0040a980 t vdrvinitfn_pmd_ring_drv 0040a9d0 t vdrvinitfn_pmd_tap_drv 0040aa00 t vdrvinitfn_pmd_vhost_drv 0040aa50 t vdrvinitfn_virtio_user_driver
Re: [lng-odp] [RFC] api: pool: add threshold limit to the pool
Regards,
Bala
On 5 June 2017 at 18:42, Stanislaw Kardach wrote:
>
>
> Best Regards,
> Stanislaw Kardach
>
> On 06/05/2017 02:54 PM, Bill Fischofer wrote:
>> On Mon, Jun 5, 2017 at 7:32 AM, Stanislaw Kardach wrote:
>>>
>>>
>>> Best Regards,
>>> Stanislaw Kardach
>>>
>>> On 06/05/2017 02:27 PM, Balasubramanian Manoharan wrote:
Adds threshold limit of the pool to the pool parameters.
This threshold limit is a percentage of total size of the pool.
Signed-off-by: Balasubramanian Manoharan
---
include/odp/api/spec/pool.h | 32
1 file changed, 32 insertions(+)
diff --git a/include/odp/api/spec/pool.h b/include/odp/api/spec/pool.h
index 6fc5b6b..1c1ebe4 100644
--- a/include/odp/api/spec/pool.h
+++ b/include/odp/api/spec/pool.h
@@ -20,6 +20,7 @@ extern "C" {
#endif
#include
+#include
/** @defgroup odp_pool ODP POOL
* Operations on a pool.
@@ -127,6 +128,9 @@ typedef struct odp_pool_capability_t {
* The value of zero means that limited only by the available
* memory size for the pool. */
uint32_t max_uarea_size;
+
+ /** Pool Threshold limit support */
+ odp_support_t pool_threshold_limit;
} pkt;
/** Timeout pool capabilities */
@@ -214,6 +218,17 @@ typedef struct odp_pool_param_t {
defined by pool capability pkt.max_uarea_size.
Specify as 0 if no user area is needed. */
uint32_t uarea_size;
+
+ /** Pool threshold limit in percentage
+ *
+ * This value denotes the threshold limit of the
pool in
+ * percentage of the total size of the pool and is
used
+ * to configure the Random Early Discard (RED).
+ * When the number of packets in the pool is greater
+ * than this value RED is initiated in the pool and
+ * further incoming packets to the pool are dropped
in
+ * a random sequence. */
+ uint8_t threshold_limit;
>>> Is threshold limit "a percentage of total size of the pool" (hence I
>>> guess 0-100) or rather an absolute value that triggers RED?
>>
>> Do we want to tie this specifically to RED or try to make things more
>> general? There are many types of flow/congestion control algorithms
>> that can be used so perhaps that should be better parameterized? Also,
>> when specifying thresholds it's customary to set high and low
>> watermarks to provide hysteresis. Some algorithms also need more than
>> one data point to control the curves, so again this suggests that we
>> need additional parameterization for this.
>>
> I'm not disputing the generalization, I've mentioned RED because it's
> right there in the comment.
> What I meant is whether this is a percentage value or absolute value (as
> in number of buffers), because commit message suggested former and this
> comments suggest latter with "When the number of packets in the pool is
> greater than this value".
So lets say the total size of the packet pool is 1024 segments and the
threshold for starting/ stopping RED is 750 segments then the
threshold limit is set as 75% rather than the absolute value of 750
segments. I will update the commit message to make it more clear.
>
> Additionally, shouldn't it be "when number of packets in this pool is
> _lower_ than this value"? Since otherwise we're saying that congestion
> algorithms are to be applied on a full pull.
I will update the documentation to indicate when RED gets dropped in
the system. The logic is RED is enabled when packets in pool is
greater than threshold and RED is disabled when packets in pool is
less than or equal to threshold limit.
Regards,
Bala
>>>
} pkt;
/** Parameters for timeout pools */
@@ -329,6 +344,23 @@ uint64_t odp_pool_to_u64(odp_pool_t hdl);
void odp_pool_param_init(odp_pool_param_t *param);
/**
+ * Set threshold limit of the pool
+ *
+ * Set the threshold limit of the pool as a percentage of the total
+ * size of the pool. This value is used to configure Random Early
Discard(RED)
+ * parameters of the pool and any incoming packets to the pool after
reaching
+ * this threshold is dropped in a random sequence.
+ *
+ * @param pool Pool handle
+ * @param threshold_limitThreshold limit of the pool.
+ *
+ * @retval 0 on success
+ * @retval -1 on failure
+ */
+
+int odp_pool_threshold_limit(odp_pool_t pool, uint8_t threshold_limit);
+
>
Re: [lng-odp] [RFC] api: pool: add threshold limit to the pool
Regards,
Bala
On 5 June 2017 at 18:02, Stanislaw Kardach wrote:
>
>
> Best Regards,
> Stanislaw Kardach
>
> On 06/05/2017 02:27 PM, Balasubramanian Manoharan wrote:
>> Adds threshold limit of the pool to the pool parameters.
>> This threshold limit is a percentage of total size of the pool.
>>
>> Signed-off-by: Balasubramanian Manoharan
>> ---
>> include/odp/api/spec/pool.h | 32
>> 1 file changed, 32 insertions(+)
>>
>> diff --git a/include/odp/api/spec/pool.h b/include/odp/api/spec/pool.h
>> index 6fc5b6b..1c1ebe4 100644
>> --- a/include/odp/api/spec/pool.h
>> +++ b/include/odp/api/spec/pool.h
>> @@ -20,6 +20,7 @@ extern "C" {
>> #endif
>>
>> #include
>> +#include
>>
>> /** @defgroup odp_pool ODP POOL
>> * Operations on a pool.
>> @@ -127,6 +128,9 @@ typedef struct odp_pool_capability_t {
>>* The value of zero means that limited only by the available
>>* memory size for the pool. */
>> uint32_t max_uarea_size;
>> +
>> + /** Pool Threshold limit support */
>> + odp_support_t pool_threshold_limit;
>> } pkt;
>>
>> /** Timeout pool capabilities */
>> @@ -214,6 +218,17 @@ typedef struct odp_pool_param_t {
>> defined by pool capability pkt.max_uarea_size.
>> Specify as 0 if no user area is needed. */
>> uint32_t uarea_size;
>> +
>> + /** Pool threshold limit in percentage
>> + *
>> + * This value denotes the threshold limit of the pool
>> in
>> + * percentage of the total size of the pool and is used
>> + * to configure the Random Early Discard (RED).
>> + * When the number of packets in the pool is greater
>> + * than this value RED is initiated in the pool and
>> + * further incoming packets to the pool are dropped in
>> + * a random sequence. */
>> + uint8_t threshold_limit;
> Is threshold limit "a percentage of total size of the pool" (hence I
> guess 0-100) or rather an absolute value that triggers RED?
Yes. It is defined as a percentage.
>
>> } pkt;
>>
>> /** Parameters for timeout pools */
>> @@ -329,6 +344,23 @@ uint64_t odp_pool_to_u64(odp_pool_t hdl);
>> void odp_pool_param_init(odp_pool_param_t *param);
>>
>> /**
>> + * Set threshold limit of the pool
>> + *
>> + * Set the threshold limit of the pool as a percentage of the total
>> + * size of the pool. This value is used to configure Random Early
>> Discard(RED)
>> + * parameters of the pool and any incoming packets to the pool after
>> reaching
>> + * this threshold is dropped in a random sequence.
>> + *
>> + * @param pool Pool handle
>> + * @param threshold_limitThreshold limit of the pool.
>> + *
>> + * @retval 0 on success
>> + * @retval -1 on failure
>> + */
>> +
>> +int odp_pool_threshold_limit(odp_pool_t pool, uint8_t threshold_limit);
>> +
>> +/**
>> * @}
>> */
>>
>>
Re: [lng-odp] [NEXT PATCH] changelog: updates for odp v1.15.0.0
On 04.06.2017 22:18, Bill Fischofer wrote: > Signed-off-by: Bill Fischofer > --- > CHANGELOG | 266 > ++ > 1 file changed, 266 insertions(+) > > diff --git a/CHANGELOG b/CHANGELOG > index a550a723..bdb5ca49 100644 [skipped] > += Crypto Enhancements > +The ODP crypto APIs receive several enhancements in this release: > + > +== New Authentication Algorithms > +Additional enumerations added for HMAC-SHA-1 and HMAC-SHA-256 authentication. > +Note that These are not yet implemented in `odp-linux` so > +`odp_crypto_capabilities()` returns zeros for these new authentication types. Sorry, Bill. This paragraph should mention HMAC-SHA-512 instead of -256. -- With best wishes Dmitry
Re: [lng-odp] [RFC] api: pool: add threshold limit to the pool
Best Regards,
Stanislaw Kardach
On 06/05/2017 02:54 PM, Bill Fischofer wrote:
> On Mon, Jun 5, 2017 at 7:32 AM, Stanislaw Kardach wrote:
>>
>>
>> Best Regards,
>> Stanislaw Kardach
>>
>> On 06/05/2017 02:27 PM, Balasubramanian Manoharan wrote:
>>> Adds threshold limit of the pool to the pool parameters.
>>> This threshold limit is a percentage of total size of the pool.
>>>
>>> Signed-off-by: Balasubramanian Manoharan
>>> ---
>>> include/odp/api/spec/pool.h | 32
>>> 1 file changed, 32 insertions(+)
>>>
>>> diff --git a/include/odp/api/spec/pool.h b/include/odp/api/spec/pool.h
>>> index 6fc5b6b..1c1ebe4 100644
>>> --- a/include/odp/api/spec/pool.h
>>> +++ b/include/odp/api/spec/pool.h
>>> @@ -20,6 +20,7 @@ extern "C" {
>>> #endif
>>>
>>> #include
>>> +#include
>>>
>>> /** @defgroup odp_pool ODP POOL
>>> * Operations on a pool.
>>> @@ -127,6 +128,9 @@ typedef struct odp_pool_capability_t {
>>>* The value of zero means that limited only by the available
>>>* memory size for the pool. */
>>> uint32_t max_uarea_size;
>>> +
>>> + /** Pool Threshold limit support */
>>> + odp_support_t pool_threshold_limit;
>>> } pkt;
>>>
>>> /** Timeout pool capabilities */
>>> @@ -214,6 +218,17 @@ typedef struct odp_pool_param_t {
>>> defined by pool capability pkt.max_uarea_size.
>>> Specify as 0 if no user area is needed. */
>>> uint32_t uarea_size;
>>> +
>>> + /** Pool threshold limit in percentage
>>> + *
>>> + * This value denotes the threshold limit of the pool
>>> in
>>> + * percentage of the total size of the pool and is
>>> used
>>> + * to configure the Random Early Discard (RED).
>>> + * When the number of packets in the pool is greater
>>> + * than this value RED is initiated in the pool and
>>> + * further incoming packets to the pool are dropped in
>>> + * a random sequence. */
>>> + uint8_t threshold_limit;
>> Is threshold limit "a percentage of total size of the pool" (hence I
>> guess 0-100) or rather an absolute value that triggers RED?
>
> Do we want to tie this specifically to RED or try to make things more
> general? There are many types of flow/congestion control algorithms
> that can be used so perhaps that should be better parameterized? Also,
> when specifying thresholds it's customary to set high and low
> watermarks to provide hysteresis. Some algorithms also need more than
> one data point to control the curves, so again this suggests that we
> need additional parameterization for this.
>
I'm not disputing the generalization, I've mentioned RED because it's
right there in the comment.
What I meant is whether this is a percentage value or absolute value (as
in number of buffers), because commit message suggested former and this
comments suggest latter with "When the number of packets in the pool is
greater than this value".
Additionally, shouldn't it be "when number of packets in this pool is
_lower_ than this value"? Since otherwise we're saying that congestion
algorithms are to be applied on a full pull.
>>
>>> } pkt;
>>>
>>> /** Parameters for timeout pools */
>>> @@ -329,6 +344,23 @@ uint64_t odp_pool_to_u64(odp_pool_t hdl);
>>> void odp_pool_param_init(odp_pool_param_t *param);
>>>
>>> /**
>>> + * Set threshold limit of the pool
>>> + *
>>> + * Set the threshold limit of the pool as a percentage of the total
>>> + * size of the pool. This value is used to configure Random Early
>>> Discard(RED)
>>> + * parameters of the pool and any incoming packets to the pool after
>>> reaching
>>> + * this threshold is dropped in a random sequence.
>>> + *
>>> + * @param pool Pool handle
>>> + * @param threshold_limitThreshold limit of the pool.
>>> + *
>>> + * @retval 0 on success
>>> + * @retval -1 on failure
>>> + */
>>> +
>>> +int odp_pool_threshold_limit(odp_pool_t pool, uint8_t threshold_limit);
>>> +
>>> +/**
>>> * @}
>>> */
>>>
>>>
Re: [lng-odp] [PATCH v1 0/9] Rework the way ODP links with other libraries
On 05.06.2017 16:06, Elo, Matias (Nokia - FI/Espoo) wrote: > >> On 5 Jun 2017, at 16:04, Dmitry Eremin-Solenikov >> wrote: >> >> On 05.06.2017 15:27, Elo, Matias (Nokia - FI/Espoo) wrote: >>> Hi, >>> >>> It seems that after this patch set the dpdk pmd drivers are not properly >>> linked anymore. The build succeeds without errors but at runtime no dpdk >>> devices are found. >> >> Which example/test fails? I tried my best to test linking with PMD drivers. >> >> -- > > I tested odp_l2fwd with Fortville NICs (i40e). $ nm test/common_plat/performance/odp_l2fwd | grep vdrv 001e7fd0 T rte_eal_vdrv_register 001e8000 T rte_eal_vdrv_unregister 0001bfe0 t vdrvinitfn_cryptodev_null_pmd_drv 0001bcf0 t vdrvinitfn_pmd_af_packet_drv 0001bd40 t vdrvinitfn_pmd_bond_drv 0001bfb0 t vdrvinitfn_pmd_null_drv 0001c010 t vdrvinitfn_pmd_pcap_drv 0001c080 t vdrvinitfn_pmd_ring_drv 0001c0d0 t vdrvinitfn_pmd_tap_drv 0001c100 t vdrvinitfn_pmd_vhost_drv 0001c150 t vdrvinitfn_virtio_user_driver > > -Matias > > -- With best wishes Dmitry
Re: [lng-odp] [PATCH v1 0/9] Rework the way ODP links with other libraries
> On 5 Jun 2017, at 16:04, Dmitry Eremin-Solenikov > wrote: > > On 05.06.2017 15:27, Elo, Matias (Nokia - FI/Espoo) wrote: >> Hi, >> >> It seems that after this patch set the dpdk pmd drivers are not properly >> linked anymore. The build succeeds without errors but at runtime no dpdk >> devices are found. > > Which example/test fails? I tried my best to test linking with PMD drivers. > > -- I tested odp_l2fwd with Fortville NICs (i40e). -Matias
Re: [lng-odp] [PATCH v1 0/9] Rework the way ODP links with other libraries
On 05.06.2017 15:27, Elo, Matias (Nokia - FI/Espoo) wrote: > Hi, > > It seems that after this patch set the dpdk pmd drivers are not properly > linked anymore. The build succeeds without errors but at runtime no dpdk > devices are found. Which example/test fails? I tried my best to test linking with PMD drivers. -- With best wishes Dmitry
Re: [lng-odp] [RFC] api: pool: add threshold limit to the pool
On Mon, Jun 5, 2017 at 7:32 AM, Stanislaw Kardach wrote:
>
>
> Best Regards,
> Stanislaw Kardach
>
> On 06/05/2017 02:27 PM, Balasubramanian Manoharan wrote:
>> Adds threshold limit of the pool to the pool parameters.
>> This threshold limit is a percentage of total size of the pool.
>>
>> Signed-off-by: Balasubramanian Manoharan
>> ---
>> include/odp/api/spec/pool.h | 32
>> 1 file changed, 32 insertions(+)
>>
>> diff --git a/include/odp/api/spec/pool.h b/include/odp/api/spec/pool.h
>> index 6fc5b6b..1c1ebe4 100644
>> --- a/include/odp/api/spec/pool.h
>> +++ b/include/odp/api/spec/pool.h
>> @@ -20,6 +20,7 @@ extern "C" {
>> #endif
>>
>> #include
>> +#include
>>
>> /** @defgroup odp_pool ODP POOL
>> * Operations on a pool.
>> @@ -127,6 +128,9 @@ typedef struct odp_pool_capability_t {
>>* The value of zero means that limited only by the available
>>* memory size for the pool. */
>> uint32_t max_uarea_size;
>> +
>> + /** Pool Threshold limit support */
>> + odp_support_t pool_threshold_limit;
>> } pkt;
>>
>> /** Timeout pool capabilities */
>> @@ -214,6 +218,17 @@ typedef struct odp_pool_param_t {
>> defined by pool capability pkt.max_uarea_size.
>> Specify as 0 if no user area is needed. */
>> uint32_t uarea_size;
>> +
>> + /** Pool threshold limit in percentage
>> + *
>> + * This value denotes the threshold limit of the pool
>> in
>> + * percentage of the total size of the pool and is used
>> + * to configure the Random Early Discard (RED).
>> + * When the number of packets in the pool is greater
>> + * than this value RED is initiated in the pool and
>> + * further incoming packets to the pool are dropped in
>> + * a random sequence. */
>> + uint8_t threshold_limit;
> Is threshold limit "a percentage of total size of the pool" (hence I
> guess 0-100) or rather an absolute value that triggers RED?
Do we want to tie this specifically to RED or try to make things more
general? There are many types of flow/congestion control algorithms
that can be used so perhaps that should be better parameterized? Also,
when specifying thresholds it's customary to set high and low
watermarks to provide hysteresis. Some algorithms also need more than
one data point to control the curves, so again this suggests that we
need additional parameterization for this.
>
>> } pkt;
>>
>> /** Parameters for timeout pools */
>> @@ -329,6 +344,23 @@ uint64_t odp_pool_to_u64(odp_pool_t hdl);
>> void odp_pool_param_init(odp_pool_param_t *param);
>>
>> /**
>> + * Set threshold limit of the pool
>> + *
>> + * Set the threshold limit of the pool as a percentage of the total
>> + * size of the pool. This value is used to configure Random Early
>> Discard(RED)
>> + * parameters of the pool and any incoming packets to the pool after
>> reaching
>> + * this threshold is dropped in a random sequence.
>> + *
>> + * @param pool Pool handle
>> + * @param threshold_limitThreshold limit of the pool.
>> + *
>> + * @retval 0 on success
>> + * @retval -1 on failure
>> + */
>> +
>> +int odp_pool_threshold_limit(odp_pool_t pool, uint8_t threshold_limit);
>> +
>> +/**
>> * @}
>> */
>>
>>
Re: [lng-odp] [RFC] api: pool: add threshold limit to the pool
Best Regards,
Stanislaw Kardach
On 06/05/2017 02:27 PM, Balasubramanian Manoharan wrote:
> Adds threshold limit of the pool to the pool parameters.
> This threshold limit is a percentage of total size of the pool.
>
> Signed-off-by: Balasubramanian Manoharan
> ---
> include/odp/api/spec/pool.h | 32
> 1 file changed, 32 insertions(+)
>
> diff --git a/include/odp/api/spec/pool.h b/include/odp/api/spec/pool.h
> index 6fc5b6b..1c1ebe4 100644
> --- a/include/odp/api/spec/pool.h
> +++ b/include/odp/api/spec/pool.h
> @@ -20,6 +20,7 @@ extern "C" {
> #endif
>
> #include
> +#include
>
> /** @defgroup odp_pool ODP POOL
> * Operations on a pool.
> @@ -127,6 +128,9 @@ typedef struct odp_pool_capability_t {
>* The value of zero means that limited only by the available
>* memory size for the pool. */
> uint32_t max_uarea_size;
> +
> + /** Pool Threshold limit support */
> + odp_support_t pool_threshold_limit;
> } pkt;
>
> /** Timeout pool capabilities */
> @@ -214,6 +218,17 @@ typedef struct odp_pool_param_t {
> defined by pool capability pkt.max_uarea_size.
> Specify as 0 if no user area is needed. */
> uint32_t uarea_size;
> +
> + /** Pool threshold limit in percentage
> + *
> + * This value denotes the threshold limit of the pool in
> + * percentage of the total size of the pool and is used
> + * to configure the Random Early Discard (RED).
> + * When the number of packets in the pool is greater
> + * than this value RED is initiated in the pool and
> + * further incoming packets to the pool are dropped in
> + * a random sequence. */
> + uint8_t threshold_limit;
Is threshold limit "a percentage of total size of the pool" (hence I
guess 0-100) or rather an absolute value that triggers RED?
> } pkt;
>
> /** Parameters for timeout pools */
> @@ -329,6 +344,23 @@ uint64_t odp_pool_to_u64(odp_pool_t hdl);
> void odp_pool_param_init(odp_pool_param_t *param);
>
> /**
> + * Set threshold limit of the pool
> + *
> + * Set the threshold limit of the pool as a percentage of the total
> + * size of the pool. This value is used to configure Random Early
> Discard(RED)
> + * parameters of the pool and any incoming packets to the pool after reaching
> + * this threshold is dropped in a random sequence.
> + *
> + * @param pool Pool handle
> + * @param threshold_limitThreshold limit of the pool.
> + *
> + * @retval 0 on success
> + * @retval -1 on failure
> + */
> +
> +int odp_pool_threshold_limit(odp_pool_t pool, uint8_t threshold_limit);
> +
> +/**
> * @}
> */
>
>
Re: [lng-odp] [PATCH v1 0/9] Rework the way ODP links with other libraries
Hi, It seems that after this patch set the dpdk pmd drivers are not properly linked anymore. The build succeeds without errors but at runtime no dpdk devices are found. -Matias > On 2 Jun 2017, at 16:59, Github ODP bot wrote: > > Currently configure tests add all libraries to AM_LDFLAGS or LIBS, thus > making all libraries link against everything. For example libodp-linux ends > up depending on libcunit. Implement fine-grained control of what gets linked > against which libraries. As a side effect, this allows us to introduce proper > linking flags to libod-linux.pc, enabling other users to use it properly. > > github > /** Email created from pull request 45 (lumag:m4) > ** https://github.com/Linaro/odp/pull/45 > ** Patch: https://github.com/Linaro/odp/pull/45.patch > ** Base sha: e6be64e01589f1aa335ea178e8314bf35ad34847 > ** Merge commit sha: 6f335855aeda94f83296fb7e0d08b293ea4121db > **/ > /github > > checkpatch.pl > total: 0 errors, 0 warnings, 0 checks, 6 lines checked > > > to_send-p-000.patch has no obvious style problems and is ready for submission. > total: 0 errors, 0 warnings, 0 checks, 60 lines checked > > > to_send-p-001.patch has no obvious style problems and is ready for submission. > total: 0 errors, 0 warnings, 0 checks, 100 lines checked > > > to_send-p-002.patch has no obvious style problems and is ready for submission. > total: 0 errors, 0 warnings, 0 checks, 32 lines checked > > > to_send-p-003.patch has no obvious style problems and is ready for submission. > total: 0 errors, 0 warnings, 0 checks, 66 lines checked > > > to_send-p-004.patch has no obvious style problems and is ready for submission. > total: 0 errors, 0 warnings, 0 checks, 18 lines checked > > > to_send-p-005.patch has no obvious style problems and is ready for submission. > total: 0 errors, 0 warnings, 0 checks, 36 lines checked > > > to_send-p-006.patch has no obvious style problems and is ready for submission. > total: 0 errors, 0 warnings, 0 checks, 42 lines checked > > > to_send-p-007.patch has no obvious style problems and is ready for submission. > total: 0 errors, 0 warnings, 0 checks, 12 lines checked > > > to_send-p-008.patch has no obvious style problems and is ready for submission. > /checkpatch.pl
[lng-odp] [RFC] api: pool: add threshold limit to the pool
Adds threshold limit of the pool to the pool parameters.
This threshold limit is a percentage of total size of the pool.
Signed-off-by: Balasubramanian Manoharan
---
include/odp/api/spec/pool.h | 32
1 file changed, 32 insertions(+)
diff --git a/include/odp/api/spec/pool.h b/include/odp/api/spec/pool.h
index 6fc5b6b..1c1ebe4 100644
--- a/include/odp/api/spec/pool.h
+++ b/include/odp/api/spec/pool.h
@@ -20,6 +20,7 @@ extern "C" {
#endif
#include
+#include
/** @defgroup odp_pool ODP POOL
* Operations on a pool.
@@ -127,6 +128,9 @@ typedef struct odp_pool_capability_t {
* The value of zero means that limited only by the available
* memory size for the pool. */
uint32_t max_uarea_size;
+
+ /** Pool Threshold limit support */
+ odp_support_t pool_threshold_limit;
} pkt;
/** Timeout pool capabilities */
@@ -214,6 +218,17 @@ typedef struct odp_pool_param_t {
defined by pool capability pkt.max_uarea_size.
Specify as 0 if no user area is needed. */
uint32_t uarea_size;
+
+ /** Pool threshold limit in percentage
+*
+* This value denotes the threshold limit of the pool in
+* percentage of the total size of the pool and is used
+* to configure the Random Early Discard (RED).
+* When the number of packets in the pool is greater
+* than this value RED is initiated in the pool and
+* further incoming packets to the pool are dropped in
+* a random sequence. */
+ uint8_t threshold_limit;
} pkt;
/** Parameters for timeout pools */
@@ -329,6 +344,23 @@ uint64_t odp_pool_to_u64(odp_pool_t hdl);
void odp_pool_param_init(odp_pool_param_t *param);
/**
+ * Set threshold limit of the pool
+ *
+ * Set the threshold limit of the pool as a percentage of the total
+ * size of the pool. This value is used to configure Random Early Discard(RED)
+ * parameters of the pool and any incoming packets to the pool after reaching
+ * this threshold is dropped in a random sequence.
+ *
+ * @param pool Pool handle
+ * @param threshold_limit Threshold limit of the pool.
+ *
+ * @retval 0 on success
+ * @retval -1 on failure
+ */
+
+int odp_pool_threshold_limit(odp_pool_t pool, uint8_t threshold_limit);
+
+/**
* @}
*/
--
1.9.1
Re: [lng-odp] [API-NEXT PATCH v6 3/6] Add arch/ files
> -Original Message- > From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@linaro.org] > Sent: Saturday, June 03, 2017 7:23 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 1 June 2017 at 02:43, Savolainen, Petri (Nokia - FI/Espoo) > wrote: > > > > > >> -Original Message- > >> From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@linaro.org] > >> Sent: Wednesday, May 31, 2017 9:03 PM > >> 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 31 May 2017 at 03:02, Savolainen, Petri (Nokia - FI/Espoo) > >> wrote: > >> > > >> > > >> >> -Original Message- > >> >> From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@linaro.org] > >> >> Sent: Wednesday, May 31, 2017 6:11 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 24 May 2017 at 06:55, Savolainen, Petri (Nokia - FI/Espoo) > >> >> wrote: > >> >> > > >> >> > > >> >> >> -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- > o...@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. > >> >> > > >> >> > >> >> Why would we have code which is not tested? Successful compilation > >> >> does not mean, the code would work. It is better that compilation > >> >> fails rather than things not work during run time. > >> >> > >> >> Does ODP claim it supports PowerPC? As far as I know, it claims it > is > >> >> supported on Linux. In that case, why not use the 'default' in arch > >> >> directory for PowerPC? > >> >> > >> >> What about MIPS? > >> >> > >> >> What about Kalray? > >> >> > >> >> What is the version of the gcc compiler that needs to be used? > >> >> > >> >> What about support for Clang on PowerPC and MIPS? What is the Clang > >> >> version we need to support? > >> >> > >> >> These builds are in ODP CI. > >> >> > >> >> We had agreed that support for PowerPC and MIPS needs to come from > >> >> respective owners. > >> > > >> > > >> > Odp-linux should build and run where
Re: [lng-odp] [NEXT PATCH] changelog: updates for odp v1.15.0.0
On 05.06.2017 02:45, Bill Fischofer wrote: > On Sun, Jun 4, 2017 at 6:17 PM, Dmitry Eremin-Solenikov > wrote: >> On 04.06.2017 22:18, Bill Fischofer wrote: >>> Signed-off-by: Bill Fischofer >>> --- >>> CHANGELOG | 266 >>> ++ >>> 1 file changed, 266 insertions(+) >>> >>> diff --git a/CHANGELOG b/CHANGELOG >>> index a550a723..bdb5ca49 100644 >>> --- a/CHANGELOG >>> +++ b/CHANGELOG >> >> [skipped] >> >>> +== New Authentication Algorithms >>> +Additional enumerations added for HMAC-SHA-1 and HMAC-SHA-256 >>> authentication. >>> +Note that These are not yet implemented in `odp-linux` so >>> +`odp_crypto_capabilities()` returns zeros for these new authentication >>> types. >> >> Not true in next branch. > > Thanks. Looks like HMAC-SHA-1 is supported but HMAC-SHA-256 is still > unsupported? SHA-256 was supported from the beginning. We added SHA-1 and SHA-512. -- With best wishes Dmitry
Re: [lng-odp] [API-NEXT PATCH] api: system_info: add function for fetching all supported huge page sizes
> On 2 Jun 2017, at 16:48, Maxim Uvarov wrote: > > On 06/02/17 12:44, Elo, Matias (Nokia - FI/Espoo) wrote: /** + * System huge page sizes in bytes + * + * Returns the number of huge page sizes supported by the system. Outputs up to + * 'num' sizes when the 'size' array pointer is not NULL. If return value is + * larger than 'num', there are more supported sizes than the function was + * allowed to output. If return value (N) is less than 'num', only sizes + * [0 ... N-1] have been written. Returned values are ordered from smallest to + * largest. + * + * @param[out] size Points to an array of huge page sizes for output + * @param num Maximum number of huge page sizes to output + * + * @return Number of supported huge page sizes + * @retval 0 on no huge pages + */ +unsigned odp_sys_huge_page_size_all(uint64_t size[], unsigned num); + >>> >>> I think it has to be int. -1 on error, 0 - no hp, > 0 pages. >>> For linux it might be similar to getpagesizes() >>> https://linux.die.net/man/3/getpagesizes >>> """ >>> if pagesizes is NULL and n_elem is 0, then the number of pages the >>> system supports is returned. Otherwise, pagesizes is filled with at most >>> n_elem page sizes. >>> """ >>> >> >> getpagesizes() returns -1 in a case of invalid function arguments. >> odp_sys_huge_page_size_all() is documented so that the application cannot >> pass invalid arguments. So an internal error would be the only possibility. >> I don't see this to be likely as the function is only reading system info. >> >> Adding -1 return value would also increase application complexity as the >> error return value would require special handling from application. >> > > We have to be consistent with all odp api functions. We do not have > unsigned function, they are int. We do have odp_pktio_max_index(), which returns unsigned, and anyway this shouldn't be a reason not to use otherwise valid return value. Regarding consistency, not returning -1 follows the same return value style as the rest of the functions in system_info.h (odp_sys_huge_page_size(), odp_sys_page_size(), odp_sys_cache_line_size()). > This function is not fast path so > additional check is ok. And -1 can be returned on permission error to > assess /proc or /sys files for example or any other internal failure. >From application point of view the outcome is still the same (no huge pages) >and returning -1 would make this function inconsistent with the other >functions in this module as noted above. -Matias
