Re: [lng-odp] [API-NEXT PATCH] linux-generic: tm: use intermediate casts to avoid strict warnings

2015-11-30 Thread Bill Fischofer
Macros would probably be a good idea, however I wanted to get this fix in
now and let Alex and/or Barry recommend further code restructure based on
their more thorough analysis.

This isn't the first time M32_ON_64 issues have been flagged.  I've added
testing with this to my own checklist and it should probably be added to
the CONTRIBUTING file and/or the Implementer's Guide.

On Mon, Nov 30, 2015 at 1:47 PM, Maxim Uvarov 
wrote:

> On 11/30/2015 21:45, Bill Fischofer wrote:
>
>> Signed-off-by: Bill Fischofer 
>> ---
>>   .../include/odp_traffic_mngr_internal.h| 15 +++---
>>   platform/linux-generic/odp_name_table.c| 58
>> --
>>   platform/linux-generic/odp_pkt_queue.c | 12 ++---
>>   platform/linux-generic/odp_sorted_list.c   | 16 +++---
>>   platform/linux-generic/odp_timer_wheel.c   | 18 +++
>>   platform/linux-generic/odp_traffic_mngr.c  |  4 +-
>>   6 files changed, 67 insertions(+), 56 deletions(-)
>>
>> diff --git a/platform/linux-generic/include/odp_traffic_mngr_internal.h
>> b/platform/linux-generic/include/odp_traffic_mngr_internal.h
>> index c2d5cf4..e48e213 100644
>> --- a/platform/linux-generic/include/odp_traffic_mngr_internal.h
>> +++ b/platform/linux-generic/include/odp_traffic_mngr_internal.h
>> @@ -48,8 +48,8 @@ typedef struct stat  file_stat_t;
>> /* Macros to convert handles to internal pointers and vice versa. */
>>   -#define MAKE_ODP_TM_HANDLE(tm_system)  ((odp_tm_t)tm_system)
>> -#define GET_TM_SYSTEM(odp_tm)  ((tm_system_t *)odp_tm)
>> +#define MAKE_ODP_TM_HANDLE(tm_system)  ((odp_tm_t)(uintptr_t)tm_system)
>> +#define GET_TM_SYSTEM(odp_tm)  ((tm_system_t *)(uintptr_t)odp_tm)
>> #define MAKE_PROFILE_HANDLE(profile_kind, tbl_idx) \
>> (((profile_kind & 0xF) << 28) | ((tbl_idx + 1) & 0xFFF))
>> @@ -59,11 +59,14 @@ typedef struct stat  file_stat_t;
>> #define GET_TBL_IDX(profile_handle)  ((profile_handle & 0xFFF) -
>> 1)
>>   -#define MAKE_ODP_TM_NODE(tm_node_obj)  ((odp_tm_node_t)(tm_node_obj))
>> -#define GET_TM_NODE_OBJ(odp_tm_node)   ((tm_node_obj_t *)(odp_tm_node))
>> +#define MAKE_ODP_TM_NODE(tm_node_obj)
>> ((odp_tm_node_t)(uintptr_t)(tm_node_obj))
>> +#define GET_TM_NODE_OBJ(odp_tm_node) \
>> +   ((tm_node_obj_t *)(uintptr_t)(odp_tm_node))
>>   -#define MAKE_ODP_TM_QUEUE(tm_queue_obj)
>> ((odp_tm_queue_t)(tm_queue_obj))
>> -#define GET_TM_QUEUE_OBJ(odp_tm_queue)   ((tm_queue_obj_t
>> *)(odp_tm_queue))
>> +#define MAKE_ODP_TM_QUEUE(tm_queue_obj) \
>> +   ((odp_tm_queue_t)(uintptr_t)(tm_queue_obj))
>> +#define GET_TM_QUEUE_OBJ(odp_tm_queue) \
>> +   ((tm_queue_obj_t *)(uintptr_t)(odp_tm_queue))
>> typedef uint64_t tm_handle_t;
>>   diff --git a/platform/linux-generic/odp_name_table.c
>> b/platform/linux-generic/odp_name_table.c
>> index 10ce099..10a760e 100644
>> --- a/platform/linux-generic/odp_name_table.c
>> +++ b/platform/linux-generic/odp_name_table.c
>> @@ -567,7 +567,7 @@ static hash_tbl_entry_t
>> make_hash_tbl_entry(name_tbl_entry_t *name_tbl_entry,
>> uint32_t new_entry_cnt;
>> new_entry_cnt   = MIN(entry_cnt + 1, 0x3F);
>> -   hash_tbl_entry  = (hash_tbl_entry_t)name_tbl_entry;
>> +   hash_tbl_entry  = (hash_tbl_entry_t)(uintptr_t)name_tbl_entry;
>> hash_tbl_entry &= ~0x3F;
>> hash_tbl_entry |= new_entry_cnt;
>> return hash_tbl_entry;
>> @@ -584,18 +584,18 @@ static name_tbl_entry_t
>> *name_hash_tbl_lookup(uint32_t hash_value)
>> if (hash_tbl_entry == 0)
>> return NULL;
>> else if ((hash_tbl_entry & 0x3F) != 0)
>> -   return (name_tbl_entry_t *)(hash_tbl_entry & ~0x3F);
>> +   return (name_tbl_entry_t *)(uintptr_t)(hash_tbl_entry &
>> ~0x3F);
>>/* This hash_tbl_entry references a secondary hash table, so
>> get
>> * some more hash_value bits and index that table.
>> */
>> hash_idx   = (hash_value >> 16) & (SECONDARY_HASH_TBL_SIZE -
>> 1);
>> -   secondary_hash = (secondary_hash_tbl_t *)hash_tbl_entry;
>> +   secondary_hash = (secondary_hash_tbl_t
>> *)(uintptr_t)hash_tbl_entry;
>> hash_tbl_entry = secondary_hash->hash_entries[hash_idx];
>> if (hash_tbl_entry == 0)
>> return NULL;
>> else if ((hash_tbl_entry & 0x3F) != 0)
>> -   return (name_tbl_entry_t *)(hash_tbl_entry & ~0x3F);
>> +   return (name_tbl_entry_t *)(uintptr_t)(hash_tbl_entry &
>> ~0x3F);
>>/* Yet again, this hash_tbl_entry references a secondary hash
>> table,
>> * so get some more hash_value bits and index that table.  We only
>> @@ -604,12 +604,12 @@ static name_tbl_entry_t
>> *name_hash_tbl_lookup(uint32_t hash_value)
>> * returning NULL.
>> */
>> hash_idx   = (hash_value >> 24) & (SECONDARY_HASH_TBL_SIZE -
>> 1);
>> -   

Re: [lng-odp] [API-NEXT PATCHv2 5/5] example: classifier: add odp_cls_cos_pool_set() api

2015-11-30 Thread Ivan Khoronzhuk



On 23.11.15 12:12, Balasubramanian Manoharan wrote:

Adds packet pool to CoS using odp_cls_cos_pool_set() api.

Signed-off-by: Balasubramanian Manoharan 
---
  example/classifier/odp_classifier.c | 37 ++---
  1 file changed, 30 insertions(+), 7 deletions(-)

diff --git a/example/classifier/odp_classifier.c 
b/example/classifier/odp_classifier.c
index 365c748..fb9f407 100644
--- a/example/classifier/odp_classifier.c
+++ b/example/classifier/odp_classifier.c
@@ -85,8 +85,12 @@ static void swap_pkt_addrs(odp_packet_t pkt_tbl[], unsigned 
len);
  static void parse_args(int argc, char *argv[], appl_args_t *appl_args);
  static void print_info(char *progname, appl_args_t *appl_args);
  static void usage(char *progname);
-static void configure_cos_queue(odp_pktio_t pktio, appl_args_t *args);
-static void configure_default_queue(odp_pktio_t pktio, appl_args_t *args);
+static void configure_cos_queue(odp_pktio_t pktio,

Seems function name doesn't correspond to the actual things it does now.


+   appl_args_t *args,
+   odp_pool_t pool);
+static void configure_default_queue(odp_pktio_t pktio,
+   appl_args_t *args,
+   odp_pool_t pool);

Seems function name doesn't correspond to the actual things it does now.


  static int convert_str_to_pmr_enum(char *token, odp_pmr_term_e *term,
   uint32_t *offset);
  static int parse_pmr_policy(appl_args_t *appl_args, char *argv[], char 
*optarg);
@@ -320,7 +324,6 @@ static void *pktio_receive_thread(void *arg)

/* Swap Eth MACs and possibly IP-addrs before sending back */
swap_pkt_addrs(, 1);
-
for (i = 0; i <  MAX_PMR_COUNT; i++) {
stats = >stats[i];
if (queue == stats->queue)
@@ -341,7 +344,9 @@ static void *pktio_receive_thread(void *arg)
return NULL;
  }

-static void configure_default_queue(odp_pktio_t pktio, appl_args_t *args)
+static void configure_default_queue(odp_pktio_t pktio,
+   appl_args_t *args,
+   odp_pool_t pool)
  {
odp_queue_param_t qparam;
odp_cos_t cos_default;
@@ -365,6 +370,11 @@ static void configure_default_queue(odp_pktio_t pktio, 
appl_args_t *args)
exit(EXIT_FAILURE);
}

+   if (0 > odp_cls_cos_pool_set(cos_default, pool)) {
+   EXAMPLE_ERR("odp_cls_cos_pool_set failed");
+   exit(EXIT_FAILURE);
+   }
+
if (0 > odp_pktio_default_cos_set(pktio, cos_default)) {
EXAMPLE_ERR("odp_pktio_default_cos_set failed");
exit(EXIT_FAILURE);
@@ -379,7 +389,9 @@ static void configure_default_queue(odp_pktio_t pktio, 
appl_args_t *args)
args->policy_count++;
  }

-static void configure_cos_queue(odp_pktio_t pktio, appl_args_t *args)
+static void configure_cos_queue(odp_pktio_t pktio,
+   appl_args_t *args,
+   odp_pool_t pool)
  {
char cos_name[ODP_COS_NAME_LEN];
char queue_name[ODP_QUEUE_NAME_LEN];
@@ -402,6 +414,7 @@ static void configure_cos_queue(odp_pktio_t pktio, 
appl_args_t *args)
};

stats->pmr = odp_pmr_create();
+   odp_queue_param_init();
qparam.sched.prio = i % odp_schedule_num_prio();
qparam.sched.sync = ODP_SCHED_SYNC_NONE;
qparam.sched.group = ODP_SCHED_GROUP_ALL;
@@ -411,11 +424,21 @@ static void configure_cos_queue(odp_pktio_t pktio, 
appl_args_t *args)
stats->queue = odp_queue_create(queue_name,
 ODP_QUEUE_TYPE_SCHED,
 );
+   if (ODP_QUEUE_INVALID == stats->queue) {
+   EXAMPLE_ERR("odp_queue_create failed");
+   exit(EXIT_FAILURE);
+   }
+
if (0 > odp_cos_queue_set(stats->cos, stats->queue)) {
EXAMPLE_ERR("odp_cos_queue_set failed");
exit(EXIT_FAILURE);
}

+   if (0 > odp_cls_cos_pool_set(stats->cos, pool)) {
+   EXAMPLE_ERR("odp_cls_cos_pool_set failed");
+   exit(EXIT_FAILURE);
+   }
+
if (0 > odp_pktio_pmr_cos(stats->pmr, pktio, stats->cos)) {
EXAMPLE_ERR("odp_pktio_pmr_cos failed");
exit(EXIT_FAILURE);
@@ -510,10 +533,10 @@ int main(int argc, char *argv[])
/* create pktio per interface */
pktio = create_pktio(args->if_name, pool);

-   configure_cos_queue(pktio, args);
+   configure_cos_queue(pktio, args, pool);

/* configure default Cos and default queue */
-   

[lng-odp] [Bug 1905] CID 154167: Memory - illegal accesses: /helper/lineartable.c

2015-11-30 Thread bugzilla-daemon
https://bugs.linaro.org/show_bug.cgi?id=1905

--- Comment #2 from Mike Holmes  ---
(In reply to huanggaoyang from comment #1)
> checked the length of the input name at the beginning.
> 74 if (strlen(name) >= ODPH_TABLE_NAME_LEN || capacity < 1 ||
> 75 capacity >= 0x1000 || key_size == 0 || value_size == 0) {
> 76 ODPH_DBG("create para input error!\n");
> 77 return NULL;
> 78 }
> 
> I think that could make sure the 'strncpy' wouln't go wrong

The strncpy will remain incorrect and the problem will surface as a fault if
that guard code is ever changed, it is hiding the real problem with the strncpy
which could generate an un-terminated string as written.

The fix is to correct the strncpy so that it has space for the delimiter and
can never cause an issue.

Maybe something like:

strncpy(tbl->name, name, ODPH_TABLE_NAME_LEN-1);

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp


Re: [lng-odp] [API-NEXT 0/3] Add validation for crypto auth decoding

2015-11-30 Thread Mike Holmes
These should apply to master not API-NEXT since they don't touch the API.


On 27 November 2015 at 03:42, Nicolas Morey-Chaisemartin 
wrote:

> This adds tests for the auth/hash check function in crypto
>
> Nicolas Morey-Chaisemartin (3):
>   validation: crypto: support auth decoding
>   validation: crypto: validate md5_check
>   validation: crypto: validate sha256_check function
>
>  test/validation/crypto/odp_crypto_test_inp.c | 35
> 
>  1 file changed, 35 insertions(+)
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>



-- 
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org  *│ *Open source software for ARM SoCs
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp


Re: [lng-odp] [API-NEXT 0/3] Add validation for crypto auth decoding

2015-11-30 Thread Nicolas Morey-Chaisemartin
Except they do not apply on master because of the API in the crypto validation 
suite brought by the AES-GCM.


On 11/30/2015 06:09 PM, Mike Holmes wrote:
> These should apply to master not API-NEXT since they don't touch the API.
>
>
> On 27 November 2015 at 03:42, Nicolas Morey-Chaisemartin  > wrote:
>
> This adds tests for the auth/hash check function in crypto
>
> Nicolas Morey-Chaisemartin (3):
>   validation: crypto: support auth decoding
>   validation: crypto: validate md5_check
>   validation: crypto: validate sha256_check function
>
>  test/validation/crypto/odp_crypto_test_inp.c | 35 
> 
>  1 file changed, 35 insertions(+)
>
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org 
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
>
>
>
> -- 
> Mike Holmes
> Technical Manager - Linaro Networking Group
> Linaro.org * **│ *Open source software for ARM SoCs
>

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp


Re: [lng-odp] [API-NEXT PATCHv2 4/5] validation: classification: add odp_cls_cos_pool_set() api

2015-11-30 Thread Bala Manoharan
Yes. This issue was pointed out by Stuart as well.
I will add detailed test case to test pool allocation with Cos.

Regards,
Bala

On 30 November 2015 at 14:49, Ivan Khoronzhuk
 wrote:
> Hi, Bala
>
> I didn't look deep enough in this validation test but seems it doesn't check
> pool assignments for CoS. To check if pool is correctly assigned to some CoS
> the
> separate pool should be created instead of using default. The default pool
> from pktio is
> used by CoS in case if special pool was not specified. And it should be
> validated with separate
> function, check if default pool is assigned in usual way and then check if
> it was replaced if
> new one is specified. In another case test will pass any way, weather pool
> assignment used or not.
>
>
> On 23.11.15 12:12, Balasubramanian Manoharan wrote:
>>
>> Assigns a packet pool to CoS using odp_cls_cos_pool_set() api.
>>
>> Signed-off-by: Balasubramanian Manoharan 
>> ---
>>   .../classification/odp_classification_test_pmr.c   | 15 ++
>>   .../classification/odp_classification_tests.c  | 24
>> ++
>>   2 files changed, 39 insertions(+)
>>
>> diff --git a/test/validation/classification/odp_classification_test_pmr.c
>> b/test/validation/classification/odp_classification_test_pmr.c
>> index 3f49d4c..5f51a03 100644
>> --- a/test/validation/classification/odp_classification_test_pmr.c
>> +++ b/test/validation/classification/odp_classification_test_pmr.c
>> @@ -153,6 +153,9 @@ static void
>> classification_test_pmr_term_tcp_dport(void)
>> queue = queue_create(queuename, true);
>> CU_ASSERT(queue != ODP_QUEUE_INVALID);
>>
>> +   retval = odp_cls_cos_pool_set(cos, pool_default);
>> +   CU_ASSERT(retval == 0);
>> +
>> retval = odp_cos_queue_set(cos, queue);
>> CU_ASSERT(retval == 0);
>>
>> @@ -240,6 +243,9 @@ static void
>> classification_test_pmr_term_tcp_sport(void)
>> queue = queue_create(queuename, true);
>> CU_ASSERT_FATAL(queue != ODP_QUEUE_INVALID);
>>
>> +   retval = odp_cls_cos_pool_set(cos, pool_default);
>> +   CU_ASSERT(retval == 0);
>> +
>> retval = odp_cos_queue_set(cos, queue);
>> CU_ASSERT(retval == 0);
>>
>> @@ -328,6 +334,9 @@ static void
>> classification_test_pmr_term_udp_dport(void)
>> retval = odp_cos_queue_set(cos, queue);
>> CU_ASSERT(retval == 0);
>>
>> +   retval = odp_cls_cos_pool_set(cos, pool_default);
>> +   CU_ASSERT(retval == 0);
>> +
>> retval = odp_pktio_pmr_cos(pmr, pktio, cos);
>> CU_ASSERT(retval == 0);
>>
>> @@ -414,6 +423,9 @@ static void
>> classification_test_pmr_term_udp_sport(void)
>> retval = odp_cos_queue_set(cos, queue);
>> CU_ASSERT(retval == 0);
>>
>> +   retval = odp_cls_cos_pool_set(cos, pool_default);
>> +   CU_ASSERT(retval == 0);
>> +
>> retval = odp_pktio_pmr_cos(pmr, pktio, cos);
>> CU_ASSERT(retval == 0);
>>
>> @@ -498,6 +510,9 @@ static void classification_test_pmr_term_ipproto(void)
>> retval = odp_cos_queue_set(cos, queue);
>> CU_ASSERT(retval == 0);
>>
>> +   retval = odp_cls_cos_pool_set(cos, pool_default);
>> +   CU_ASSERT(retval == 0);
>> +
>> retval = odp_pktio_pmr_cos(pmr, pktio, cos);
>> CU_ASSERT(retval == 0);
>>
>> diff --git a/test/validation/classification/odp_classification_tests.c
>> b/test/validation/classification/odp_classification_tests.c
>> index 3944d94..bec7053 100644
>> --- a/test/validation/classification/odp_classification_tests.c
>> +++ b/test/validation/classification/odp_classification_tests.c
>> @@ -154,6 +154,10 @@ void configure_cls_pmr_chain(void)
>>queue_list[CLS_PMR_CHAIN_SRC]);
>> CU_ASSERT(retval == 0);
>>
>> +   retval = odp_cls_cos_pool_set(cos_list[CLS_PMR_CHAIN_SRC],
>> + pool_default);
>> +   CU_ASSERT(retval == 0);
>> +
>> sprintf(cosname, "DstCos");
>> cos_list[CLS_PMR_CHAIN_DST] = odp_cos_create(cosname);
>> CU_ASSERT_FATAL(cos_list[CLS_PMR_CHAIN_DST] != ODP_COS_INVALID);
>> @@ -173,6 +177,10 @@ void configure_cls_pmr_chain(void)
>>queue_list[CLS_PMR_CHAIN_DST]);
>> CU_ASSERT(retval == 0);
>>
>> +   retval = odp_cls_cos_pool_set(cos_list[CLS_PMR_CHAIN_DST],
>> + pool_default);
>> +   CU_ASSERT(retval == 0);
>> +
>> parse_ipv4_string(CLS_PMR_CHAIN_SADDR, , );
>> match.term = ODP_PMR_SIP_ADDR;
>> match.val = 
>> @@ -273,6 +281,9 @@ void configure_pktio_default_cos(void)
>>queue_list[CLS_DEFAULT]);
>> CU_ASSERT(retval == 0);
>>
>> +   retval = odp_cls_cos_pool_set(cos_list[CLS_DEFAULT],
>> pool_default);
>> +   CU_ASSERT(retval == 0);
>> +
>> retval = odp_pktio_default_cos_set(pktio_loop,
>> 

[lng-odp] [API-NEXT PATCH] linux-generic: tm: use intermediate casts to avoid strict warnings

2015-11-30 Thread Bill Fischofer
Signed-off-by: Bill Fischofer 
---
 .../include/odp_traffic_mngr_internal.h| 15 +++---
 platform/linux-generic/odp_name_table.c| 58 --
 platform/linux-generic/odp_pkt_queue.c | 12 ++---
 platform/linux-generic/odp_sorted_list.c   | 16 +++---
 platform/linux-generic/odp_timer_wheel.c   | 18 +++
 platform/linux-generic/odp_traffic_mngr.c  |  4 +-
 6 files changed, 67 insertions(+), 56 deletions(-)

diff --git a/platform/linux-generic/include/odp_traffic_mngr_internal.h 
b/platform/linux-generic/include/odp_traffic_mngr_internal.h
index c2d5cf4..e48e213 100644
--- a/platform/linux-generic/include/odp_traffic_mngr_internal.h
+++ b/platform/linux-generic/include/odp_traffic_mngr_internal.h
@@ -48,8 +48,8 @@ typedef struct stat  file_stat_t;
 
 /* Macros to convert handles to internal pointers and vice versa. */
 
-#define MAKE_ODP_TM_HANDLE(tm_system)  ((odp_tm_t)tm_system)
-#define GET_TM_SYSTEM(odp_tm)  ((tm_system_t *)odp_tm)
+#define MAKE_ODP_TM_HANDLE(tm_system)  ((odp_tm_t)(uintptr_t)tm_system)
+#define GET_TM_SYSTEM(odp_tm)  ((tm_system_t *)(uintptr_t)odp_tm)
 
 #define MAKE_PROFILE_HANDLE(profile_kind, tbl_idx) \
(((profile_kind & 0xF) << 28) | ((tbl_idx + 1) & 0xFFF))
@@ -59,11 +59,14 @@ typedef struct stat  file_stat_t;
 
 #define GET_TBL_IDX(profile_handle)  ((profile_handle & 0xFFF) - 1)
 
-#define MAKE_ODP_TM_NODE(tm_node_obj)  ((odp_tm_node_t)(tm_node_obj))
-#define GET_TM_NODE_OBJ(odp_tm_node)   ((tm_node_obj_t *)(odp_tm_node))
+#define MAKE_ODP_TM_NODE(tm_node_obj) ((odp_tm_node_t)(uintptr_t)(tm_node_obj))
+#define GET_TM_NODE_OBJ(odp_tm_node) \
+   ((tm_node_obj_t *)(uintptr_t)(odp_tm_node))
 
-#define MAKE_ODP_TM_QUEUE(tm_queue_obj)  ((odp_tm_queue_t)(tm_queue_obj))
-#define GET_TM_QUEUE_OBJ(odp_tm_queue)   ((tm_queue_obj_t *)(odp_tm_queue))
+#define MAKE_ODP_TM_QUEUE(tm_queue_obj) \
+   ((odp_tm_queue_t)(uintptr_t)(tm_queue_obj))
+#define GET_TM_QUEUE_OBJ(odp_tm_queue) \
+   ((tm_queue_obj_t *)(uintptr_t)(odp_tm_queue))
 
 typedef uint64_t tm_handle_t;
 
diff --git a/platform/linux-generic/odp_name_table.c 
b/platform/linux-generic/odp_name_table.c
index 10ce099..10a760e 100644
--- a/platform/linux-generic/odp_name_table.c
+++ b/platform/linux-generic/odp_name_table.c
@@ -567,7 +567,7 @@ static hash_tbl_entry_t 
make_hash_tbl_entry(name_tbl_entry_t *name_tbl_entry,
uint32_t new_entry_cnt;
 
new_entry_cnt   = MIN(entry_cnt + 1, 0x3F);
-   hash_tbl_entry  = (hash_tbl_entry_t)name_tbl_entry;
+   hash_tbl_entry  = (hash_tbl_entry_t)(uintptr_t)name_tbl_entry;
hash_tbl_entry &= ~0x3F;
hash_tbl_entry |= new_entry_cnt;
return hash_tbl_entry;
@@ -584,18 +584,18 @@ static name_tbl_entry_t *name_hash_tbl_lookup(uint32_t 
hash_value)
if (hash_tbl_entry == 0)
return NULL;
else if ((hash_tbl_entry & 0x3F) != 0)
-   return (name_tbl_entry_t *)(hash_tbl_entry & ~0x3F);
+   return (name_tbl_entry_t *)(uintptr_t)(hash_tbl_entry & ~0x3F);
 
/* This hash_tbl_entry references a secondary hash table, so get
* some more hash_value bits and index that table.
*/
hash_idx   = (hash_value >> 16) & (SECONDARY_HASH_TBL_SIZE - 1);
-   secondary_hash = (secondary_hash_tbl_t *)hash_tbl_entry;
+   secondary_hash = (secondary_hash_tbl_t *)(uintptr_t)hash_tbl_entry;
hash_tbl_entry = secondary_hash->hash_entries[hash_idx];
if (hash_tbl_entry == 0)
return NULL;
else if ((hash_tbl_entry & 0x3F) != 0)
-   return (name_tbl_entry_t *)(hash_tbl_entry & ~0x3F);
+   return (name_tbl_entry_t *)(uintptr_t)(hash_tbl_entry & ~0x3F);
 
/* Yet again, this hash_tbl_entry references a secondary hash table,
* so get some more hash_value bits and index that table.  We only
@@ -604,12 +604,12 @@ static name_tbl_entry_t *name_hash_tbl_lookup(uint32_t 
hash_value)
* returning NULL.
*/
hash_idx   = (hash_value >> 24) & (SECONDARY_HASH_TBL_SIZE - 1);
-   secondary_hash = (secondary_hash_tbl_t *)hash_tbl_entry;
+   secondary_hash = (secondary_hash_tbl_t *)(uintptr_t)hash_tbl_entry;
hash_tbl_entry = secondary_hash->hash_entries[hash_idx];
if (hash_tbl_entry == 0)
return NULL;
else if ((hash_tbl_entry & 0x3F) != 0)
-   return (name_tbl_entry_t *)(hash_tbl_entry & ~0x3F);
+   return (name_tbl_entry_t *)(uintptr_t)(hash_tbl_entry & ~0x3F);
 
return NULL;
 }
@@ -655,7 +655,8 @@ static hash_tbl_entry_t secondary_hash_add(name_tbl_entry_t 
*name_tbl_entry,
 
hash_tbl_entry = secondary_hash->hash_entries[hash_idx];
entry_cnt  = hash_tbl_entry & 0x3F;
-   first_entry= (name_tbl_entry_t *)(hash_tbl_entry & ~0x3F);
+ 

Re: [lng-odp] [API-NEXT PATCHv12 0/3] Egress Traffic Manager

2015-11-30 Thread Mike Holmes
On 25 November 2015 at 08:25, Bill Fischofer 
wrote:

>
>
> On Wed, Nov 25, 2015 at 6:45 AM, Anders Roxell 
> wrote:
>
>> On 25 November 2015 at 11:09, Maxim Uvarov 
>> wrote:
>> > On 11/25/2015 01:01, Bill Fischofer wrote:
>> >>
>> >>
>> >>
>> >> On Tuesday, November 24, 2015, Mike Holmes > >> > wrote:
>> >>
>> >>
>> >>
>> >> On 24 November 2015 at 15:29, Bill Fischofer
>> >> > >> >
>> wrote:
>> >>
>> >>
>> >>
>> >> On Tuesday, November 24, 2015, Maxim Uvarov
>> >> > >> >
>> wrote:
>> >>
>> >> On 11/24/2015 21:31, Anders Roxell wrote:
>> >>
>> >> On 2015-11-24 17:26, Maxim Uvarov wrote:
>> >>
>> >> Merged!
>> >>
>> >> Patches were long time in the list for review,
>> >> passed all validations tests
>> >> and all comments which
>> >> we got are fixed.
>> >>
>> >> I can see a number of problems by putting these
>> >> patches in.
>> >>
>> >> Good finding but unfortunately too late. It became very
>> >> common now review patches
>> >> only after they were merged :( And probably you missed
>> >> discussion about accepting
>> >> these patches on last 3 meeting.
>> >>
>> >> 1. The author is not correctly set! It Should be Barry
>> >> and not Bill!
>> >>
>> >> yes, that comment was some version later and I thought it
>> >> was fixed.
>> >> It would be good to document Barry's contribution.
>> >>
>> >> Maybe it's reasonable add Easy Chip copyright to
>> >> include/odp/api/traffic_mngr.h
>> >> with Barry's name?
>> >>
>> >>
>> >> Barry should be listed in all modules.  He's the main sign
>> >> off.  Not sure why that wouldn't be picked up.
>> >>
>> >>
>> >> 2. Petri has not given his Reviewed-by on the API
>> patch.
>> >>
>> >> We all know that this TM api was widely discussed on
>> >> Sprint. Some minor changes
>> >> can fix later.  For not it's not candidate for next
>> >> release until we polish it in  api-next
>> >> branch.
>> >>
>> >>
>> >> Petri gave his verbal review/agreement to merge these to
>> >> api-next. Agree that should be recorded.
>> >>
>> >>
>> >> 3. This breaks a build of 32bit on a 64 bit machine.
>> >>
>> >> Should this really go in? I think we should revert
>> this.
>> >>
>> >> That is also serious. Can you please ping me tomorrow
>> >> during day time? I switched from my synthetic tests to
>> >> odp-check
>> >> and it did not show any errors. I want to understand what
>> >> is the difference between ci odp-check and mine.
>> >>
>> >>
>> >> Check-ODP build-all.sh passes for me.  How are we expected to
>> >> test this?  I thought check-odp did that .
>> >>
>> >>
>> >> It does, it can do many (too many :) ) things - check out the
>> --help
>> >>
>> >> This would catch it  M32_ON_64=1 GIT_BRANCH=api-next ./build.sh
>> >>
>> >>
>> >> I thought build-all covered all variants. Is that not the case?
>>
>> Bill, we don't run all variants with build-all.sh because people
>> complained that it
>> took too long time to run... that is why we have build-all.sh and
>> detailed-analysis.sh
>>
>>
> So detailed-analysis.sh is the real build-all and build-all should really
> be called build-some?
>

They do have different purposes, and both are just wrappers around the real
tool build.sh which has many options which are called in sequence by these
scripts.

detailed-analysis.sh
builds lcov, doxygen, the user docs, clang and sparse - so it tests more of
the things people forget that are not in the normal build / test loop

build-all.sh
builds all the architectures we use so, 32 and 64 bit versions on AMD(X86)
and ARM and its intent is to discover cross compiling issues

amd64
amd32 on 64
arm
arm64

If there patches for better names, new collections of calls or additions to
the help description send them to lng-check-...@lists.linaro.org


>
>
>> >
>> >
>> > Previously Anders said that I should not use  build-all and use
>> > apply-and-biuld.sh.
>>
>> So, I've said that you have to run every patch through apply-and-build.sh
>> yes
>> that is true!
>>
>> A long time back you reported a bug in the build-all.sh script yes,
>> and I fixed that.
>>
>> > So I'm
>> > also a little bit disappointed.
>>
>> Me too.
>>
>> > Why M32_ON_64 is not turned 

Re: [lng-odp] [API-NEXT 0/3] Add validation for crypto auth decoding

2015-11-30 Thread Mike Holmes
On 30 November 2015 at 12:28, Nicolas Morey-Chaisemartin 
wrote:

> Except they do not apply on master because of the API in the crypto
> validation suite brought by the AES-GCM.
>

Fair comment :)
I did run them against api-next and saw no issues there, but I will double
check, thanks.


>
>
>
> On 11/30/2015 06:09 PM, Mike Holmes wrote:
>
> These should apply to master not API-NEXT since they don't touch the API.
>
>
> On 27 November 2015 at 03:42, Nicolas Morey-Chaisemartin <
> nmo...@kalray.eu> wrote:
>
>> This adds tests for the auth/hash check function in crypto
>>
>> Nicolas Morey-Chaisemartin (3):
>>   validation: crypto: support auth decoding
>>   validation: crypto: validate md5_check
>>   validation: crypto: validate sha256_check function
>>
>>  test/validation/crypto/odp_crypto_test_inp.c | 35
>> 
>>  1 file changed, 35 insertions(+)
>>
>> ___
>> lng-odp mailing list
>> lng-odp@lists.linaro.org
>> https://lists.linaro.org/mailman/listinfo/lng-odp
>>
>
>
>
> --
> Mike Holmes
> Technical Manager - Linaro Networking Group
> Linaro.org  *│ *Open source software for ARM SoCs
>
>
>


-- 
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org  *│ *Open source software for ARM SoCs
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp


Re: [lng-odp] [API-NEXT PATCH] api: pool: redefine packet user area init

2015-11-30 Thread Zoltan Kiss



On 30/11/15 13:31, Savolainen, Petri (Nokia - FI/Espoo) wrote:



diff --git a/include/odp/api/pool.h b/include/odp/api/pool.h
index 01f770f..7b258c3 100644
--- a/include/odp/api/pool.h
+++ b/include/odp/api/pool.h
@@ -42,21 +42,25 @@ extern "C" {
   #define ODP_POOL_NAME_LEN  32

   /**
- * Packet user area initializer callback function for pools.
+ * Packet user area initialize callback function
*
- * @param pkt   Handle of the packet
- * @param uarea_init_argOpaque pointer defined in

odp_pool_param_t

+ * Packet pool uses this callback function to initialize user area in

each

+ * packet. The function is called once (per packet) in pool creation

phase for

+ * both persistent (user_area.persistent is set) and non-persistent

user areas.

+ * Additionally, it is called to re-initialize non-persistent user

area, when

+ * ODP has overwritten the area content.
*
- * @note If the application specifies this pointer, it expects that

every buffer

- * is initialized exactly once with it when the underlying memory is

allocated.

- * It is not called from odp_packet_alloc(), unless the platform

chooses to

- * allocate the memory at that point. Applications can only assume that

this

- * callback is called once before the packet is first used. Any

subsequent

- * change to the user area might be preserved after odp_packet_free()

is called,

- * so applications should take care of (re)initialization if they

change data

- * preset by this function.
+ * @param pool   Packet pool handle
+ * @param init_arg   User defined 'user_area.init_arg' pointer in
+ *   odp_pool_param_t
+ * @param user_area  Pointer to packet user area to initialize
+ * @param size   User area size in bytes
+ * @param pkt_index  Index of the packet. The range is from 0 to number

of

+ *   packet in the pool (packet pool param 'num') minus

one.

Why would an application need this? It's not visible to the app. Also,


It's helpful for e.g. allocating per packet context memory at this point. This 
is just unique, opaque index from 0 to num - 1.

my_packet_ctx_t my_packet_ctx[MAX_PACKETS];

user_area_init(odp_pool_t pool, void *init_arg, void *user_area, uint32_t size, 
uint32_t pkt_index) {

my_packet_user_area = user_area;
my_packet_user_area->pkt_ctx = _packet_ctx[pkt_index];

}


And why couldn't you use the packet handle for that? This just seems to 
me an another unique id for the packet.
This example seems to me like using the user area to store a pointer for 
an application allocated piece of memory related for that particular 
buffer. That would be a duplication of the functionality of 
odp_packet_user_ptr()






ODP-DPDK for example allocates some extra number of rte_mbuf's because
the per-thread caching can sit on packets, which in extreme cases makes
impossible to allocate 'num' packets. See this for details:

https://git.linaro.org/lng/odp-
dpdk.git/commitdiff/e1ac6c797539a62ee6b93554a1f0a7f5ba433a36

So, what would be pkt_index for these extra buffers? (NB. 'num' is only
the number we MUST provide, nothing says we can't have more than that)



'num' is: "The number of packets that the pool must provide that are packet length 'len' bytes 
or smaller" and "The number of packets may be less than 'num' when packets are larger 
than 'len'"

So, it's actually the maximum number of packets that can be allocated from the 
pool.


There could be less than 'num' packets if packets are bigger, yes, but 
the description doesn't restrict us that we can't have more.
If you get the bill in the restaurant, you "must provide" that amount of 
money, but nothing prevents you to pay more.



Any per thread caching causes variation to actual number in-flight, but any 
time there should not be more than 'num' packets.


If you have a per-thread object cache for packets (sounds sensible to 
avoid locking during allocation), after a short time you'll have an 
arbitrary number of packets in those caches, waiting to be used. If the 
app requests 'num' while all packets are free, you can't always fulfill 
that request because some of the packets will be in other thread's 
cache. There is an unit test to check that, that's when I introduced 
this overcommit in odp-dpdk.
Of course that opens up the possibility that you can have more than 
'num' packets allocated at one point, but I don't see it as a problem. 
And as I said above, it isn't really forbidden in the spec.
If you say there is a good reason to make that restriction, we should 
disable such object caches. (and change the API spec to be more explicit 
on that restriction)




However, for OVS we need the odp_packet_t of the packet, so we can call
ODP functions on the packet. And if you pass it, everything except
init_arg becomes unnecessary, because you can just take them with the
ODP functions.


The packet handle and all packet metadata are (potentially) invalid at this 
point.


My idea of this 

Re: [lng-odp] [API-NEXT PATCH] api: init: allow implementation to use private ways for its own configuration

2015-11-30 Thread Zoltan Kiss



On 30/11/15 12:02, Savolainen, Petri (Nokia - FI/Espoo) wrote:




-Original Message-
From: EXT Zoltan Kiss [mailto:zoltan.k...@linaro.org]
Sent: Thursday, November 26, 2015 4:35 PM
To: Savolainen, Petri (Nokia - FI/Espoo); lng-odp@lists.linaro.org
Cc: bill.fischo...@linaro.org; mike.hol...@linaro.org
Subject: Re: [API-NEXT PATCH] api: init: allow implementation to use
private ways for its own configuration



On 26/11/15 09:25, Savolainen, Petri (Nokia - FI/Espoo) wrote:




-Original Message-
From: EXT Zoltan Kiss [mailto:zoltan.k...@linaro.org]
Sent: Tuesday, November 24, 2015 4:45 PM
To: lng-odp@lists.linaro.org
Cc: bill.fischo...@linaro.org; Savolainen, Petri (Nokia - FI/Espoo);
mike.hol...@linaro.org
Subject: Re: [API-NEXT PATCH] api: init: allow implementation to use
private ways for its own configuration

Could anyone review this? Petri?

On 18/11/15 16:22, Zoltan Kiss wrote:

This could help the existing configuration methods to be used if the
application prefers that. The platform_params should always supersede

that

though.

Signed-off-by: Zoltan Kiss 

diff --git a/include/odp/api/init.h b/include/odp/api/init.h
index 737ff6d..24f4f3a 100644
--- a/include/odp/api/init.h
+++ b/include/odp/api/init.h
@@ -141,6 +141,9 @@ typedef struct odp_platform_init_t {
 *
 * This function must be called once before calling any other ODP

API

 * functions.
+ * The underlying implementation may have another way to get

configuration

+ * related to platform_params (e.g. environmental variable,

configuration

+ * file), but if the application passes it, it should always

supersede.

 *
 * @param params  Those parameters that are interpreted by

the

ODP API.

 *Use NULL to set all parameters to their

defaults.




Which configuration should supersede which?


"but if the application passes it, it should always supersede."

As this is in the comment of odp_platform_init_t, sed
s/"it"/"odp_platform_init_t"/g



+ * The underlying implementation may have another way to get configuration
+ * related to platform_params (e.g. environmental variable, configuration
+ * file), but if the application passes it, it should always supersede.

It's not clear from this sentence if application:
- passes "another way" (e.g. config file) which supersedes "platform_params" ,or
- passes "platform_params" which supersedes "another way"

Both can be understood as "it".


Ok, I'll rephrase it as "but if the application passes platform_params"








Isn't it that way around that config files and env params are usually

used to override the hard coded configuration. So, you'd build your
application with a default config, but would use extra methods to override
the hard coded default config. If hard coded config all ways overrides,
you cannot try other configs without rebuilding (which may not be even
possible if you just have received the app binary).

Yes, but noone talks about hardcoded configuration here. Every sensible
application should have a sensible way to get configured, including ODP
platform parameters of the user's choice to be passed to the actual
platform. Of course the application can choose to detect the platform
runtime and apply a default if nothing else configured to it, but it
would be still more relevant than some platform defaults.


For example, if an (3rd party) application has been built before a new 
(implementation specific) parameter was introduced, the app would init all 
params to defaults (with odp_xxx_params_init()) and set those that it cares 
about. Any new params would be in defaults unless you rebuild the app, which 
may not be always possible.


This is an example of a badly written application. As I said above, 
platform_params shouldn't be used for passing hardcoded default parameters.
I can add a sentence to remind people about having a sensible way of 
configuration, and not trying to figure out the impossible at the time 
of development.




Another example, optimal configuration is not known at build time. The system 
is composed from multiple ODP apps, any single developer does not know which 
ODP configuration is optimal or even possible when apps are integrated together.


Yes, that's why your app should have a way to get its configuration. 
E.g. command line options, a config file. OVS has OVSDB, at the moment 
you can also store a string called odp_platform_params there, which will 
be passed to the platform in platform_params.
If there is a platform which needs something else than a string, then 
OVS can provide a way for that. In any case, that's the implementation's 
internal detail, the application may or may not know how to handle that, 
and how to handle if it changes.
But it's not ODP's business, that's why we are providing only an opaque 
type here. This patch just tries to encourage apps and platforms to pass 
it here, because IF the app is able to configure the platform (e.g. 

[lng-odp] [PATCH 2/3] CHANGELOG: initial revision

2015-11-30 Thread Mike Holmes
With the addition of an RPM package to the existing debian package we
need to have a single change log for the ODP API and the linux-generic
implementation.
The debian and RPM change logs then just list packaging changes.

Create an initial copy of the old debian log.

Signed-off-by: Mike Holmes 
---
 CHANGELOG | 520 ++
 1 file changed, 520 insertions(+)
 create mode 100644 CHANGELOG

diff --git a/CHANGELOG b/CHANGELOG
new file mode 100644
index 000..cd8c387
--- /dev/null
+++ b/CHANGELOG
@@ -0,0 +1,520 @@
+opendataplane (1.4.1.0)
+   * Validation
+   - pktio: test transmit error recovery
+   - schedule: add chaos test
+   - check return code from odp_queue_lock_count()
+   - scheduler: test ordered queue reorder processing
+   - pktio: initialize queue parameters correctly
+   - pktio: test for transmit error handling
+   - pktio: add support for direct receive
+   - pktio: pass interface index rather than name
+   - pktio: fix start_stop test
+   - test: l2fwd: separate rx and tx drop counters
+   - test: l2fwd: increase burst size
+   - test: l2fwd: optimize statistics usage
+   - test: l2fwd: optimize queue mode
+   - test: l2fwd: start pktios after worker thread create
+   - test: l2fwd: added option to disable error check
+   - example/ipsec: Increase ip_data_len for Tunnel mode
+   - example: ipsec: check push_tail return code
+   * General:
+   - linux-generic: pktio: handle transmit errors correctly
+   - pktio socket_mmap: recover from transmit errors but 1890
+   - pktio: increase MTU of loop interface
+   - ordered queues: fix race condition during order release
+ and out of order.
+   - configure: move HAVE_PCAP AM_CONDITIONAL to configure.ac
+   * ODP helper:
+   - linux: checkpatch cleaning for helper/linux.c
+   - linux: examine the cause for child process termination
+   - linux: request SIGTERM if parent process dies
+
+opendataplane (1.4.0.0)
+   * API:
+   - ** Classification **
+   - odp_cos_set_queue() renamed to odp_cos_queue_set()
+   - int odp_cos_set_drop renamed to odp_cos_drop_set()
+   - new: odp_queue_t odp_cos_queue(odp_cos_t cos_id)
+   - new: odp_drop_e odp_cos_drop(odp_cos_t cos_id)
+   - ODP_PMR_CUSTOM_FRAME support in classification
+   - odp_pmr_create() arguments passing change to use struct
+   - odp_pmr_match_set_create() added id argument
+   - ** Config **
+   - new: odp_config_...() API introduced instead of ODP_CONFIG_ defines
+   - ** Cpu, Threads and Scheduler **
+   - new: uint64_t odp_cpu_cycles(void)
+   - new: uint64_t odp_cpu_cycles_diff(uint64_t c1, uint64_t c2);
+   - new: uint64_t odp_cpu_cycles_max(void);
+   - new: uint64_t odp_cpu_cycles_resolution(void);
+   - odp_cpumask_def_worker() renamed to odp_cpumask_default_worker()
+   - odp_cpumask_def_control() renamed to odp_cpumask_default_control()
+   - odp init extended with num worker and control threads
+   - new: int odp_queue_lock_count(odp_queue_t queue);
+   - refine api doc for scheduler and schedule orderd locks
+   - argument of odp_schedule_order_lock() and odp_schedule_order_unlock 
changed to unsigned
+   - new: int odp_thread_count_max(void)
+   - ** Packet **
+   - new: uint32_t odp_packet_flow_hash(odp_packet_t pkt)
+   - new: void odp_packet_flow_hash_set(odp_packet_t pkt, uint32_t 
flow_hash)
+   - new: int odp_packet_has_flow_hash(odp_packet_t pkt);
+   - new: void odp_packet_has_flow_hash_clr(odp_packet_t pkt);
+   - ** Pktio **
+   - pktio can be configuread as receive or transmit only
+   - pktio: refined api doc for start() and stop()
+   - new: void odp_pktio_param_init(odp_pktio_param_t *param)
+   * ODP docs:
+   - implementers-guide: update names of test module libraries
+   - implementers-guide: update section on skipping tests
+   * Test framework
+   - update README files
+   - renaming module libs
+   - add odp_cunit_update() to modify registered tests
+   - add ability to mark tests inactive
+   * Validation
+   - ** Classification **
+   - Add fix for classification tests
+   - remove redundant pool lookup function
+   - remove redundant sequence number check
+   - use tcp data offset field to calculate data offset
+   - move destroy_inq() to common file
+   - add odp_pktio_param_init() API
+   - added additional suite to test individual PMRs
+   - use a structure instead of many args for odp_pmr_create
+   - Add init calls for queue parameters
+   - syntax correction for CU_ASSERT
+   - Add init calls for pool parameters
+   - queue and drop policy API name change
+   - Queue parameter init calls
+   - ** Cpu, Threads and Scheduler **
+   - rename odp_cpumask_def to 

[lng-odp] [PATCH 3/3] update version number from v1.4.1.0 to v1.5.0.0

2015-11-30 Thread Mike Holmes
Signed-off-by: Mike Holmes 
---
 CHANGELOG | 34 ++
 include/odp/api/version.h |  4 ++--
 pkg/debian/changelog  |  5 +
 pkg/rpm/odp.spec  |  2 ++
 4 files changed, 43 insertions(+), 2 deletions(-)

diff --git a/CHANGELOG b/CHANGELOG
index cd8c387..89966a9 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -1,3 +1,37 @@
+opendataplane (1.5.0.0)
+   * API:
+   - api: buffer: add functions to alloc/free multiple buffers at once
+   - api: cpu: change order of arguments for diff function
+   - api: crypto: add AES128-CBC encrypt/decrypt methods
+   - api: crypto: add HMAC-SHA-256-128 support
+   - api: crypto: move enums from platform types to odp and rename to fit 
the API format
+   - api: packet: add functions to alloc/free multiple packets at once
+   - api: queue: add odp_queue_info() function to retrieve queue 
information
+   - api: time: change order of arguments for diff function
+   - api: time: unbind CPU cycles from time API
+   * Validation
+   - performance: odp_pktio_perf: fix potential overflow in wait loop
+   - test/example: avoid "cycle" word usage
+   - ability to specify test install directory
+   - buffer: add tests for buffer alloc/free multi functions
+   - crypto: add test for AES128 CBC
+   - crypto: add test for HMAC-SHA-256-128
+   - crypto: limit packet size to maximum supported by platform
+   - packet: add tests for packet alloc/free multi functions
+   - queue: api validation tests for odp_queue_info()
+   - remove strict dependency on CUnit 2.1-3
+   - scheduler: add missing ticketlock unlock
+   * General:
+   - rpm packaging support
+   - linux-generic: config: increase ODP_CONFIG_SCHED_GRPS to 256
+   - linux-generic: cpumask: warn that CPU0 is used by control and worker 
thread
+   - linux-generic: packet: add implementation for packet alloc/free multi
+   - linux-generic: pool: add buffer_alloc_multi function
+   - linux-generic: pool: add implementation for buffer alloc/free multi
+   - linux-generic: queue: add odp_queue_info() function
+   - linux-generic: validation: add run-test script for post install 
testing
+   - platform: move list of API files to Makefile.inc so it is common to 
all platforms
+
 opendataplane (1.4.1.0)
* Validation
- pktio: test transmit error recovery
diff --git a/include/odp/api/version.h b/include/odp/api/version.h
index 8912177..58bb7ec 100644
--- a/include/odp/api/version.h
+++ b/include/odp/api/version.h
@@ -37,7 +37,7 @@ extern "C" {
  * Introduction of major new features or changes. APIs with different major
  * versions are likely not backward compatible.
  */
-#define ODP_VERSION_API_MAJOR 4
+#define ODP_VERSION_API_MAJOR 5
 
 /**
  * ODP API minor version
@@ -46,7 +46,7 @@ extern "C" {
  * to the API. For an API with common generation and major version, but with
  * different minor numbers the two versions are backward compatible.
  */
-#define ODP_VERSION_API_MINOR 1
+#define ODP_VERSION_API_MINOR 0
 
 /**
  * Returns ODP API version string
diff --git a/pkg/debian/changelog b/pkg/debian/changelog
index 1983a9a..7680cf1 100644
--- a/pkg/debian/changelog
+++ b/pkg/debian/changelog
@@ -1,3 +1,8 @@
+opendataplane (1.5.0.0-1) unstable; urgency=low
+   * ODP release v1.5
+
+ -- Maxim Uvarov   Mon, 30 Nov 2015 13:08:43 +0300
+
 opendataplane (1.4.1.0-1) unstable; urgency=low
* Validation
- pktio: test transmit error recovery
diff --git a/pkg/rpm/odp.spec b/pkg/rpm/odp.spec
index aa57476..e76fe58 100644
--- a/pkg/rpm/odp.spec
+++ b/pkg/rpm/odp.spec
@@ -68,5 +68,7 @@ and guides in HTMLformats.
 %post -p /sbin/ldconfig
 %postun -p /sbin/ldconfig
 %changelog
+* Mon Nov 30 2015 - mike.holmes (at) linaro.org
+- ODP release v1.5
 * Tue Nov 10 2015 - anders.roxell (at) linaro.org
 - Initial rpm release, ODP release v1.4
-- 
2.5.0

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp


[lng-odp] [PATCH 1/3] Revert "update version number from v1.4.1.0 to v1.5.0.0"

2015-11-30 Thread Mike Holmes
This reverts commit 8cb80afde4a9e00cfea4bed5ecf721d6577793c4.
---
 include/odp/api/version.h |  4 ++--
 pkg/debian/changelog  | 36 
 2 files changed, 2 insertions(+), 38 deletions(-)

diff --git a/include/odp/api/version.h b/include/odp/api/version.h
index 58bb7ec..8912177 100644
--- a/include/odp/api/version.h
+++ b/include/odp/api/version.h
@@ -37,7 +37,7 @@ extern "C" {
  * Introduction of major new features or changes. APIs with different major
  * versions are likely not backward compatible.
  */
-#define ODP_VERSION_API_MAJOR 5
+#define ODP_VERSION_API_MAJOR 4
 
 /**
  * ODP API minor version
@@ -46,7 +46,7 @@ extern "C" {
  * to the API. For an API with common generation and major version, but with
  * different minor numbers the two versions are backward compatible.
  */
-#define ODP_VERSION_API_MINOR 0
+#define ODP_VERSION_API_MINOR 1
 
 /**
  * Returns ODP API version string
diff --git a/pkg/debian/changelog b/pkg/debian/changelog
index 088cc77..1983a9a 100644
--- a/pkg/debian/changelog
+++ b/pkg/debian/changelog
@@ -1,39 +1,3 @@
-opendataplane (1.5.0.0-1) unstable; urgency=low
-   * API:
-   - api: buffer: add functions to alloc/free multiple buffers at once
-   - api: cpu: change order of arguments for diff function
-   - api: crypto: add AES128-CBC encrypt/decrypt methods
-   - api: crypto: add HMAC-SHA-256-128 support
-   - api: crypto: move enums from platform types to odp and rename to fit 
the API format
-   - api: packet: add functions to alloc/free multiple packets at once
-   - api: queue: add odp_queue_info() function to retrieve queue 
information
-   - api: time: change order of arguments for diff function
-   - api: time: unbind CPU cycles from time API
-   * Validation
-   - performance: odp_pktio_perf: fix potential overflow in wait loop
-   - test/example: avoid "cycle" word usage
-   - ability to specify test install directory
-   - buffer: add tests for buffer alloc/free multi functions
-   - crypto: add test for AES128 CBC
-   - crypto: add test for HMAC-SHA-256-128
-   - crypto: limit packet size to maximum supported by platform
-   - packet: add tests for packet alloc/free multi functions
-   - queue: api validation tests for odp_queue_info()
-   - remove strict dependency on CUnit 2.1-3
-   - scheduler: add missing ticketlock unlock
-   * General:
-   - rpm packaging support
-   - linux-generic: config: increase ODP_CONFIG_SCHED_GRPS to 256
-   - linux-generic: cpumask: warn that CPU0 is used by control and worker 
thread
-   - linux-generic: packet: add implementation for packet alloc/free multi
-   - linux-generic: pool: add buffer_alloc_multi function
-   - linux-generic: pool: add implementation for buffer alloc/free multi
-   - linux-generic: queue: add odp_queue_info() function
-   - linux-generic: validation: add run-test script for post install 
testing
-   - platform: move list of API files to Makefile.inc so it is common to 
all platforms
-
- -- Maxim Uvarov   Mon, 30 Nov 2015 13:08:43 +0300
-
 opendataplane (1.4.1.0-1) unstable; urgency=low
* Validation
- pktio: test transmit error recovery
-- 
2.5.0

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp


Re: [lng-odp] [API-NEXT PATCH v3 6/7] api: time: make odp_local_time to be monotonic wall time

2015-11-30 Thread Savolainen, Petri (Nokia - FI/Espoo)
Why not just have one patch for API ...

include/odp/api/time.h|  3 +-


... and move everything else in another patch(es). The old implementation and 
usage of the API is still functionally correct after API change. It may not be 
optimal (does not exploit the knowledge that local time cannot wrap), but it's 
functionally correct. Or do you expect that CLOCK_MONOTONIC_RAW wraps?


-Petri 


> -Original Message-
> From: EXT Ivan Khoronzhuk [mailto:ivan.khoronz...@linaro.org]
> Sent: Monday, November 30, 2015 4:19 PM
> To: Savolainen, Petri (Nokia - FI/Espoo); lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [API-NEXT PATCH v3 6/7] api: time: make
> odp_local_time to be monotonic wall time
> 
> 
> 
> On 30.11.15 16:07, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> >
> >
> >> -Original Message-
> >> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> EXT
> >> Ivan Khoronzhuk
> >> Sent: Monday, November 23, 2015 11:21 PM
> >> To: lng-odp@lists.linaro.org
> >> Subject: [lng-odp] [API-NEXT PATCH v3 6/7] api: time: make
> odp_local_time
> >> to be monotonic wall time
> >>
> >> It's more convenient the local time to be a monotonic wall time.
> >> That means time starts from 0 and not wraps. It allows to use local
> >> time in similar manner as it's supposed to be used with global time
> >> and the 64-bit timer is enough to guarantee it.
> >>
> >> Signed-off-by: Ivan Khoronzhuk 
> >
> >
> >
> >
> >> diff --git a/include/odp/api/time.h b/include/odp/api/time.h
> >> index 50a0bf5..9865d81 100644
> >> --- a/include/odp/api/time.h
> >> +++ b/include/odp/api/time.h
> >> @@ -45,7 +45,8 @@ extern "C" {
> >>* Current local time
> >>*
> >>* Returns current local time stamp value. The local time source
> provides
> >> high
> >> - * resolution time.
> >> + * resolution time, it is initialized to zero during ODP startup and
> will
> >> not
> >> + * wrap around in at least 10 years.
> >>*
> >>* @return Local time stamp.
> >>*/
> >
> >
> > I think it's better to separate this the API spec into its own patch.
> All other changes here may or may not depend on it, but those can follow
> in the next patch. It's significant spec change and an implementer may
> miss it now.
> 
> Ok. I will split it on linux-generic + api and examples/testes patches.
> But I think this simplification is not very eficient as api change patch
> will contain:
>   include/odp/api/time.h|  3 +-
>   platform/linux-generic/include/odp_internal.h |  2 +
>   platform/linux-generic/odp_schedule.c |  9 ++--
>   platform/linux-generic/odp_time.c | 61 +++--
> --
> 
> and example/test patch:
>   example/generator/odp_generator.c | 10 ++---
>   test/performance/odp_pktio_perf.c | 26 ++--
>   test/validation/pktio/pktio.c | 21 -
> 
> >
> > -Petri
> >
> >
> >
> >
> >
> >
> 
> --
> Regards,
> Ivan Khoronzhuk
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp


Re: [lng-odp] [API-NEXT PATCH v3 7/7] validation: time: align tests with current time API

2015-11-30 Thread Savolainen, Petri (Nokia - FI/Espoo)


> -Original Message-
> From: EXT Ivan Khoronzhuk [mailto:ivan.khoronz...@linaro.org]
> Sent: Monday, November 30, 2015 4:47 PM
> To: Savolainen, Petri (Nokia - FI/Espoo); lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [API-NEXT PATCH v3 7/7] validation: time: align
> tests with current time API
> 
> 
> 
> On 30.11.15 16:17, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> >
> >
> >> -Original Message-
> >> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> EXT
> >> Ivan Khoronzhuk
> >> Sent: Monday, November 23, 2015 11:21 PM
> >> To: lng-odp@lists.linaro.org
> >> Subject: [lng-odp] [API-NEXT PATCH v3 7/7] validation: time: align
> tests
> >> with current time API
> >>
> >> Add test for odp_time_sum, odp_time_cmp, odp_time_to_u64 APIs.
> >> Sophisticate a little tests for odp_time_diff, odp_time_local_from_ns,
> >> odp_time_local_to_ns APIs. Check time on monotony.
> >>
> >> Signed-off-by: Ivan Khoronzhuk 
> >> ---
> >>   test/validation/time/time.c | 224
> >> +++-
> >>   test/validation/time/time.h |   7 +-
> >>   2 files changed, 207 insertions(+), 24 deletions(-)
> >>
> >> diff --git a/test/validation/time/time.c b/test/validation/time/time.c
> >> index 3d05a6f..8f5dfe6 100644
> >> --- a/test/validation/time/time.c
> >> +++ b/test/validation/time/time.c
> >> @@ -11,13 +11,114 @@
> >>   #define TOLERANCE 1
> >>   #define BUSY_LOOP_CNT 100
> >>
> >> +/* check that related conversions come back to the same value */
> >> +void time_test_odp_conversion(void)
> >> +{
> >> +  uint64_t ns1, ns2;
> >> +  odp_time_t time;
> >> +  uint64_t upper_limit, lower_limit;
> >> +
> >> +  ns1 = 100;
> >> +  time = odp_time_local_from_ns(ns1);
> >> +
> >> +  ns2 = odp_time_to_ns(time);
> >> +
> >> +  /* need to check within arithmetic tolerance that the same
> >> +   * value in ns is returned after conversions */
> >> +  upper_limit = ns1 + TOLERANCE;
> >> +  lower_limit = ns1 - TOLERANCE;
> >> +  CU_ASSERT((ns2 <= upper_limit) && (ns2 >= lower_limit));
> >> +
> >> +  ns1 = 60 * 11 * ODP_TIME_SEC_IN_NS;
> >> +  time = odp_time_local_from_ns(ns1);
> >> +
> >> +  ns2 = odp_time_to_ns(time);
> >> +
> >> +  /* need to check within arithmetic tolerance that the same
> >> +   * value in ns is returned after conversions */
> >> +  upper_limit = ns1 + TOLERANCE;
> >> +  lower_limit = ns1 - TOLERANCE;
> >> +  CU_ASSERT((ns2 <= upper_limit) && (ns2 >= lower_limit));
> >> +}
> >> +
> >> +void time_test_monotony(void)
> >> +{
> >> +  volatile int count = 0;
> >> +  odp_time_t t1, t2, t3;
> >> +  uint64_t ns1, ns2, ns3;
> >> +
> >> +  t1 = odp_time_local();
> >> +
> >> +  while (count < BUSY_LOOP_CNT) {
> >> +  count++;
> >> +  };
> >> +
> >> +  t2 = odp_time_local();
> >> +
> >> +  while (count < BUSY_LOOP_CNT * 5) {
> >> +  count++;
> >> +  };
> >> +
> >> +  t3 = odp_time_local();
> >
> >
> > These loops are short in execution time. So, the test will very likely
> to pass also when local time would wrap e.g. every 4 sec.
> I can increase BUSY_LOOP_CNT, replace 100 number that is based on some
> freq like 3GHz and minimum resolution.
> The resolution API I'm going to add after this series is applied, so for
> now lets suppose that this is 10ms.
> 
> then BYSY_LOOP_CNT for testing minimum time is = 0.01 * 3GHz = 3000.
> For some boards it can take in 3 times longer.
> 
> 
> >
> > At least one test should run at least e.g. 4sec to verify wrap around.
> I don't suppose here that 32-bit counter is used for time API, so check is
> redundancy. But,
> for long time intervals I've used conversion functions, it's checked in
> time_test_conversion test.
> It's done in order to not increase time for validating time API.
> If you OK to increase validation test for time API at least on 5sec I have
> no objection.
> 
> Currently ODP doesn't have correct way to read frequency for all arches.
> So lets count 4seconds based on some freq = 3GHz, then iteration_num =
> 4sec * 3000 = 12 000 000 000.
> It's bigger than 4seconds as iteration takes more than one simple cycle.
> Then:
> BUSY_LOOP_CNT = 1000, and test for time more that 4 sec => BUSY_LOOP_CNT =
> 1000 * 12.
> 
> But pay attention, that it can take more than 4sec * 3 * 2cycles = 24
> seconds on boards with 3 time less frequency.
> So test can be longer on half of minute!.


You don't need to busy loop >4sec on every step. It's enough that the entire 
time API validation test duration is >4sec, which is reasonable when we are 
testing time accuracy. Even a duration of >1sec would be good to test, since 
all those timespec.sec + timespec.nsec calculations may have bugs that are 
visible only when .sec is incremented.

-Petri



> 
> I propose to leave test as is here, and hope that time_test_odp_conversion
> caught issues.
> What do you say?
> 
> >
> > -Petri
> >
> 
> --
> Regards,
> Ivan Khoronzhuk
___
lng-odp mailing list

Re: [lng-odp] [PATCH] linux-generic: pktio: add tap pktio type

2015-11-30 Thread Ilya Maximets
OK. I try to prepare them.

Best regards, Ilya Maximets.

On 27.11.2015 13:19, Maxim Uvarov wrote:
> Hello Ilya,
> 
> Thanks for sending that patch. Tap pktio should be interesting.
> To accept it we also need coverage validation tests.
> 
> Best regards,
> Maxim.
> 
> 
> On 11/25/2015 17:15, Ilya Maximets wrote:
>> Creates a new pktio type that allows for creating and
>> sending/receiving packets through TAP interface.
>> It is intended for use as a simple conventional communication
>> method between applications that use kernel network stack
>> (ping, ssh, iperf, etc.) and ODP applications for the purpose
>> of functional testing and can be used as it is with some
>> of the existing example applications.
>>
>> To use this interface the name passed to odp_pktio_open() must
>> begin with "tap:" and be in the format:
>>
>>   tap:iface
>>
>> iface   the name of TAP device to be created.
>>
>> TUN/TAP kernel module should be loaded to use this pktio.
>> There should be no device named 'iface' in the system.
>> The total length of the 'iface' is limited by IF_NAMESIZE.
>>
>> Signed-off-by: Ilya Maximets 
>> ---
>>   platform/linux-generic/Makefile.am |   2 +
>>   .../linux-generic/include/odp_packet_io_internal.h |   3 +
>>   platform/linux-generic/include/odp_packet_tap.h|  17 ++
>>   platform/linux-generic/pktio/io_ops.c  |   1 +
>>   platform/linux-generic/pktio/tap.c | 251 
>> +
>>   5 files changed, 274 insertions(+)
>>   create mode 100644 platform/linux-generic/include/odp_packet_tap.h
>>   create mode 100644 platform/linux-generic/pktio/tap.c
>>
>> diff --git a/platform/linux-generic/Makefile.am 
>> b/platform/linux-generic/Makefile.am
>> index 610e04d..8395bda 100644
>> --- a/platform/linux-generic/Makefile.am
>> +++ b/platform/linux-generic/Makefile.am
>> @@ -91,6 +91,7 @@ noinst_HEADERS = \
>>${srcdir}/include/odp_packet_io_queue.h \
>>${srcdir}/include/odp_packet_netmap.h \
>>${srcdir}/include/odp_packet_socket.h \
>> +  ${srcdir}/include/odp_packet_tap.h \
>>${srcdir}/include/odp_pool_internal.h \
>>${srcdir}/include/odp_queue_internal.h \
>>${srcdir}/include/odp_schedule_internal.h \
>> @@ -119,6 +120,7 @@ __LIB__libodp_la_SOURCES = \
>> pktio/netmap.c \
>> pktio/socket.c \
>> pktio/socket_mmap.c \
>> +   pktio/tap.c \
>> odp_pool.c \
>> odp_queue.c \
>> odp_rwlock.c \
>> diff --git a/platform/linux-generic/include/odp_packet_io_internal.h 
>> b/platform/linux-generic/include/odp_packet_io_internal.h
>> index 1a1118c..de29557 100644
>> --- a/platform/linux-generic/include/odp_packet_io_internal.h
>> +++ b/platform/linux-generic/include/odp_packet_io_internal.h
>> @@ -22,6 +22,7 @@ extern "C" {
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>   #include 
>>   #include 
>>   #include 
>> @@ -78,6 +79,7 @@ struct pktio_entry {
>>   #ifdef HAVE_PCAP
>>  pkt_pcap_t pkt_pcap;/**< Using pcap for IO */
>>   #endif
>> +pkt_tap_t pkt_tap;  /**< using TAP for IO */
>>  };
>>  enum {
>>  STATE_START = 0,
>> @@ -157,6 +159,7 @@ extern const pktio_if_ops_t loopback_pktio_ops;
>>   #ifdef HAVE_PCAP
>>   extern const pktio_if_ops_t pcap_pktio_ops;
>>   #endif
>> +extern const pktio_if_ops_t tap_pktio_ops;
>>   extern const pktio_if_ops_t * const pktio_if_ops[];
>>   
>>   #ifdef __cplusplus
>> diff --git a/platform/linux-generic/include/odp_packet_tap.h 
>> b/platform/linux-generic/include/odp_packet_tap.h
>> new file mode 100644
>> index 000..2d442fb
>> --- /dev/null
>> +++ b/platform/linux-generic/include/odp_packet_tap.h
>> @@ -0,0 +1,17 @@
>> +/* Copyright (c) 2015, Ilya Maximets 
>> + * All rights reserved.
>> + *
>> + * SPDX-License-Identifier: BSD-3-Clause
>> + */
>> +
>> +#ifndef ODP_PACKET_TAP_H_
>> +#define ODP_PACKET_TAP_H_
>> +
>> +#include 
>> +
>> +typedef struct {
>> +int fd; /**< file descriptor for tap interface */
>> +odp_pool_t pool;/**< pool to alloc packets from */
>> +} pkt_tap_t;
>> +
>> +#endif
>> diff --git a/platform/linux-generic/pktio/io_ops.c 
>> b/platform/linux-generic/pktio/io_ops.c
>> index 3b344e6..1933abc 100644
>> --- a/platform/linux-generic/pktio/io_ops.c
>> +++ b/platform/linux-generic/pktio/io_ops.c
>> @@ -18,6 +18,7 @@ const pktio_if_ops_t * const pktio_if_ops[]  = {
>>   #ifdef HAVE_PCAP
>>  _pktio_ops,
>>   #endif
>> +_pktio_ops,
>>  _mmap_pktio_ops,
>>  _mmsg_pktio_ops,
>>  NULL
>> diff --git a/platform/linux-generic/pktio/tap.c 
>> b/platform/linux-generic/pktio/tap.c
>> new file mode 100644
>> index 000..e629986
>> --- /dev/null
>> +++ 

Re: [lng-odp] [API-NEXT PATCH] api: init: allow implementation to use private ways for its own configuration

2015-11-30 Thread Savolainen, Petri (Nokia - FI/Espoo)


> -Original Message-
> From: EXT Zoltan Kiss [mailto:zoltan.k...@linaro.org]
> Sent: Thursday, November 26, 2015 4:35 PM
> To: Savolainen, Petri (Nokia - FI/Espoo); lng-odp@lists.linaro.org
> Cc: bill.fischo...@linaro.org; mike.hol...@linaro.org
> Subject: Re: [API-NEXT PATCH] api: init: allow implementation to use
> private ways for its own configuration
> 
> 
> 
> On 26/11/15 09:25, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> >
> >
> >> -Original Message-
> >> From: EXT Zoltan Kiss [mailto:zoltan.k...@linaro.org]
> >> Sent: Tuesday, November 24, 2015 4:45 PM
> >> To: lng-odp@lists.linaro.org
> >> Cc: bill.fischo...@linaro.org; Savolainen, Petri (Nokia - FI/Espoo);
> >> mike.hol...@linaro.org
> >> Subject: Re: [API-NEXT PATCH] api: init: allow implementation to use
> >> private ways for its own configuration
> >>
> >> Could anyone review this? Petri?
> >>
> >> On 18/11/15 16:22, Zoltan Kiss wrote:
> >>> This could help the existing configuration methods to be used if the
> >>> application prefers that. The platform_params should always supersede
> >> that
> >>> though.
> >>>
> >>> Signed-off-by: Zoltan Kiss 
> >>>
> >>> diff --git a/include/odp/api/init.h b/include/odp/api/init.h
> >>> index 737ff6d..24f4f3a 100644
> >>> --- a/include/odp/api/init.h
> >>> +++ b/include/odp/api/init.h
> >>> @@ -141,6 +141,9 @@ typedef struct odp_platform_init_t {
> >>> *
> >>> * This function must be called once before calling any other ODP
> API
> >>> * functions.
> >>> + * The underlying implementation may have another way to get
> >> configuration
> >>> + * related to platform_params (e.g. environmental variable,
> >> configuration
> >>> + * file), but if the application passes it, it should always
> supersede.
> >>> *
> >>> * @param params  Those parameters that are interpreted by
> the
> >> ODP API.
> >>> *Use NULL to set all parameters to their
> >> defaults.
> >>>
> >
> > Which configuration should supersede which?
> 
> "but if the application passes it, it should always supersede."
> 
> As this is in the comment of odp_platform_init_t, sed
> s/"it"/"odp_platform_init_t"/g


+ * The underlying implementation may have another way to get configuration
+ * related to platform_params (e.g. environmental variable, configuration
+ * file), but if the application passes it, it should always supersede.

It's not clear from this sentence if application:
- passes "another way" (e.g. config file) which supersedes "platform_params" ,or
- passes "platform_params" which supersedes "another way"

Both can be understood as "it".


> 
> 
> > Isn't it that way around that config files and env params are usually
> used to override the hard coded configuration. So, you'd build your
> application with a default config, but would use extra methods to override
> the hard coded default config. If hard coded config all ways overrides,
> you cannot try other configs without rebuilding (which may not be even
> possible if you just have received the app binary).
> 
> Yes, but noone talks about hardcoded configuration here. Every sensible
> application should have a sensible way to get configured, including ODP
> platform parameters of the user's choice to be passed to the actual
> platform. Of course the application can choose to detect the platform
> runtime and apply a default if nothing else configured to it, but it
> would be still more relevant than some platform defaults.

For example, if an (3rd party) application has been built before a new 
(implementation specific) parameter was introduced, the app would init all 
params to defaults (with odp_xxx_params_init()) and set those that it cares 
about. Any new params would be in defaults unless you rebuild the app, which 
may not be always possible.

Another example, optimal configuration is not known at build time. The system 
is composed from multiple ODP apps, any single developer does not know which 
ODP configuration is optimal or even possible when apps are integrated together.


> 
> >
> > It may vary per parameter and application, which parameters are possible
> to override (without application 100% controlling it).
> 
> I'm not sure I understand that. A parameter is something which is
> configurable, by definition. In other words, it's possible to override
> it. "always supersede" implies to me that, but you can suggest a better
> phrasing.

For example, maximum number of CPUs may be hard coded in an app, but any CPU 
MHz goes.

int my_cpu[32];

// crash if plat_config.max_cpu > 32
my_cpu[odp_cpu_id()].foo = 1;

// any value is OK
printf("CPU MHz %u", odp_cpu_mhz());


// Fill defaults (from config file)
// max_cpu = 64, max_mhz = 1000 (on this SoC)
plat_xyz_config_init_params(_config);
plat_config.max_cpu = 32;
plat_config.max_mhz = 500; // 500MHz was max on the old SoC, could be 
overridden with some plat specific way


> 
> > Can we say anything else than platform configuration 

Re: [lng-odp] [API-NEXT PATCH v3 6/7] api: time: make odp_local_time to be monotonic wall time

2015-11-30 Thread Savolainen, Petri (Nokia - FI/Espoo)


> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
> Ivan Khoronzhuk
> Sent: Monday, November 23, 2015 11:21 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [API-NEXT PATCH v3 6/7] api: time: make odp_local_time
> to be monotonic wall time
> 
> It's more convenient the local time to be a monotonic wall time.
> That means time starts from 0 and not wraps. It allows to use local
> time in similar manner as it's supposed to be used with global time
> and the 64-bit timer is enough to guarantee it.
> 
> Signed-off-by: Ivan Khoronzhuk 




> diff --git a/include/odp/api/time.h b/include/odp/api/time.h
> index 50a0bf5..9865d81 100644
> --- a/include/odp/api/time.h
> +++ b/include/odp/api/time.h
> @@ -45,7 +45,8 @@ extern "C" {
>   * Current local time
>   *
>   * Returns current local time stamp value. The local time source provides
> high
> - * resolution time.
> + * resolution time, it is initialized to zero during ODP startup and will
> not
> + * wrap around in at least 10 years.
>   *
>   * @return Local time stamp.
>   */


I think it's better to separate this the API spec into its own patch. All other 
changes here may or may not depend on it, but those can follow in the next 
patch. It's significant spec change and an implementer may miss it now.

-Petri






___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp


Re: [lng-odp] [API-NEXT PATCHv2 4/5] validation: classification: add odp_cls_cos_pool_set() api

2015-11-30 Thread Ivan Khoronzhuk

Hi, Bala

I didn't look deep enough in this validation test but seems it doesn't check
pool assignments for CoS. To check if pool is correctly assigned to some CoS the
separate pool should be created instead of using default. The default pool from 
pktio is
used by CoS in case if special pool was not specified. And it should be 
validated with separate
function, check if default pool is assigned in usual way and then check if it 
was replaced if
new one is specified. In another case test will pass any way, weather pool 
assignment used or not.

On 23.11.15 12:12, Balasubramanian Manoharan wrote:

Assigns a packet pool to CoS using odp_cls_cos_pool_set() api.

Signed-off-by: Balasubramanian Manoharan 
---
  .../classification/odp_classification_test_pmr.c   | 15 ++
  .../classification/odp_classification_tests.c  | 24 ++
  2 files changed, 39 insertions(+)

diff --git a/test/validation/classification/odp_classification_test_pmr.c 
b/test/validation/classification/odp_classification_test_pmr.c
index 3f49d4c..5f51a03 100644
--- a/test/validation/classification/odp_classification_test_pmr.c
+++ b/test/validation/classification/odp_classification_test_pmr.c
@@ -153,6 +153,9 @@ static void classification_test_pmr_term_tcp_dport(void)
queue = queue_create(queuename, true);
CU_ASSERT(queue != ODP_QUEUE_INVALID);

+   retval = odp_cls_cos_pool_set(cos, pool_default);
+   CU_ASSERT(retval == 0);
+
retval = odp_cos_queue_set(cos, queue);
CU_ASSERT(retval == 0);

@@ -240,6 +243,9 @@ static void classification_test_pmr_term_tcp_sport(void)
queue = queue_create(queuename, true);
CU_ASSERT_FATAL(queue != ODP_QUEUE_INVALID);

+   retval = odp_cls_cos_pool_set(cos, pool_default);
+   CU_ASSERT(retval == 0);
+
retval = odp_cos_queue_set(cos, queue);
CU_ASSERT(retval == 0);

@@ -328,6 +334,9 @@ static void classification_test_pmr_term_udp_dport(void)
retval = odp_cos_queue_set(cos, queue);
CU_ASSERT(retval == 0);

+   retval = odp_cls_cos_pool_set(cos, pool_default);
+   CU_ASSERT(retval == 0);
+
retval = odp_pktio_pmr_cos(pmr, pktio, cos);
CU_ASSERT(retval == 0);

@@ -414,6 +423,9 @@ static void classification_test_pmr_term_udp_sport(void)
retval = odp_cos_queue_set(cos, queue);
CU_ASSERT(retval == 0);

+   retval = odp_cls_cos_pool_set(cos, pool_default);
+   CU_ASSERT(retval == 0);
+
retval = odp_pktio_pmr_cos(pmr, pktio, cos);
CU_ASSERT(retval == 0);

@@ -498,6 +510,9 @@ static void classification_test_pmr_term_ipproto(void)
retval = odp_cos_queue_set(cos, queue);
CU_ASSERT(retval == 0);

+   retval = odp_cls_cos_pool_set(cos, pool_default);
+   CU_ASSERT(retval == 0);
+
retval = odp_pktio_pmr_cos(pmr, pktio, cos);
CU_ASSERT(retval == 0);

diff --git a/test/validation/classification/odp_classification_tests.c 
b/test/validation/classification/odp_classification_tests.c
index 3944d94..bec7053 100644
--- a/test/validation/classification/odp_classification_tests.c
+++ b/test/validation/classification/odp_classification_tests.c
@@ -154,6 +154,10 @@ void configure_cls_pmr_chain(void)
   queue_list[CLS_PMR_CHAIN_SRC]);
CU_ASSERT(retval == 0);

+   retval = odp_cls_cos_pool_set(cos_list[CLS_PMR_CHAIN_SRC],
+ pool_default);
+   CU_ASSERT(retval == 0);
+
sprintf(cosname, "DstCos");
cos_list[CLS_PMR_CHAIN_DST] = odp_cos_create(cosname);
CU_ASSERT_FATAL(cos_list[CLS_PMR_CHAIN_DST] != ODP_COS_INVALID);
@@ -173,6 +177,10 @@ void configure_cls_pmr_chain(void)
   queue_list[CLS_PMR_CHAIN_DST]);
CU_ASSERT(retval == 0);

+   retval = odp_cls_cos_pool_set(cos_list[CLS_PMR_CHAIN_DST],
+ pool_default);
+   CU_ASSERT(retval == 0);
+
parse_ipv4_string(CLS_PMR_CHAIN_SADDR, , );
match.term = ODP_PMR_SIP_ADDR;
match.val = 
@@ -273,6 +281,9 @@ void configure_pktio_default_cos(void)
   queue_list[CLS_DEFAULT]);
CU_ASSERT(retval == 0);

+   retval = odp_cls_cos_pool_set(cos_list[CLS_DEFAULT], pool_default);
+   CU_ASSERT(retval == 0);
+
retval = odp_pktio_default_cos_set(pktio_loop, cos_list[CLS_DEFAULT]);
CU_ASSERT(retval == 0);
  }
@@ -323,6 +334,9 @@ void configure_pktio_error_cos(void)
retval = odp_cos_queue_set(cos_list[CLS_ERROR], queue_list[CLS_ERROR]);
CU_ASSERT(retval == 0);

+   retval = odp_cls_cos_pool_set(cos_list[CLS_ERROR], pool_default);
+   CU_ASSERT(retval == 0);
+
retval = odp_pktio_error_cos_set(pktio_loop, cos_list[CLS_ERROR]);
CU_ASSERT(retval == 0);
  }
@@ -411,6 +425,10 @@ void configure_cos_with_l2_priority(void)

Re: [lng-odp] [PATCH v3 0/3] add warnings to improve timer usage

2015-11-30 Thread Maxim Uvarov

Merged,
Maxim.

On 11/19/2015 17:30, Ivan Khoronzhuk wrote:

This series is intended to help user to set timer in frames
that OS allows him. The timer resolution shouldn't be better than
system allows, minimum timeout shouldn't be more than resolution,
and warn application that CPU0, that is used for tick notification
handling, can have impact on worker thread running on CPU0.

This patch series helps to close a bug:
https://bugs.linaro.org/show_bug.cgi?id=1449

Since v2:
   linux-generic: cpumask: warn that CPU0 is used by control and worker
- corrected commmit and warning message

Since v1:
- printed name of the timer pool while ticker overrun
- use "high" resolution instead of "low"

Ivan Khoronzhuk (3):
   example: timer: warn if timeout less than resolution
   linux-generic: odp_timer: warn if tick is late
   linux-generic: cpumask: warn that CPU0 is used by control and worker
 thread

  example/timer/odp_timer_test.c| 3 +++
  platform/linux-generic/odp_cpumask_task.c | 4 
  platform/linux-generic/odp_timer.c| 7 +++
  3 files changed, 14 insertions(+)



___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp


Re: [lng-odp] [API-NEXT PATCH] api: pool: redefine packet user area init

2015-11-30 Thread Savolainen, Petri (Nokia - FI/Espoo)
> > +
> > +   /** 0: User area content may be
> overwritten when
> > +  packet is stored in the pool. If
> init
> > +  callback function is defined, it
> is
> > +  called to (re)initialize user
> area when
> > +  ever ODP has overwritten it. Init
> is not
> > +  necessarily called on every
> alloc, only
> > +  when needed (in pool creation and
> after
> > +  each overwrite).
> 
> How does the implementation know about the overwrite of the user-area?
> wouldn't it be better for the application to handle initialisation of
> user-are before freeing the buffer back to the pool.
> Maybe some example could explain the use-case this proposal is trying to
> solve.

"... whenever ODP has overwritten it." If *implementation* overwrites it, it 
calls init before passing it back to app.


> > +   1: User area content must remain
> constant
> > +  when packet is stored in the
> pool. If
> > +  init callback function is
> defined, it is
> > +  called once in pool creation.
> > +  */
> 
> IMO, instead of specifying that the user-area remains constant we can
> specify that implementation does not modify the content when the
> buffer is returned and reallocated from the pool.

API spec is from application point of view. App sees that all bytes have 
remained the same while the packet was in the pool. Of course implementation 
can store entire area, overwrite and restore it before returning the packet 
back to the app.

Another word can be used, but "constant" is application view.

-Petri

___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp


Re: [lng-odp] [API-NEXT PATCH v3 1/7] validation: time: don't assign int directly to odp_time_t

2015-11-30 Thread Savolainen, Petri (Nokia - FI/Espoo)


> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
> Ivan Khoronzhuk
> Sent: Monday, November 23, 2015 11:21 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [API-NEXT PATCH v3 1/7] validation: time: don't assign
> int directly to odp_time_t
> 
> Under opaque type can be structure that cannot be used with direct
> values, So, use conversion functions to get time_t to avoid build
> issues.
> 
> Signed-off-by: Ivan Khoronzhuk 
> ---
>  test/validation/time/time.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/test/validation/time/time.c b/test/validation/time/time.c
> index f70c776..3d05a6f 100644
> --- a/test/validation/time/time.c
> +++ b/test/validation/time/time.c
> @@ -36,8 +36,8 @@ void time_test_odp_negative_diff(void)
>  {
>   odp_time_t diff, t1, t2;
> 
> - t1 = 10;
> - t2 = 5;
> + t1 = odp_time_local_from_ns(10);
> + t2 = odp_time_local_from_ns(5);
>   diff = odp_time_diff(t2, t1);
>   CU_ASSERT(odp_time_cmp(diff, ODP_TIME_NULL) > 0);


This requires <5ns resolution, which is may not be available all times.

Also "negative_diff" hints that it should be diff(5, 10) instead of diff(10, 
5), which is positive after the diff API chance.

-Petri


>  }
> --
> 1.9.1
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp


Re: [lng-odp] [API-NEXT PATCH v3 6/7] api: time: make odp_local_time to be monotonic wall time

2015-11-30 Thread Ivan Khoronzhuk



On 30.11.15 16:07, Savolainen, Petri (Nokia - FI/Espoo) wrote:




-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
Ivan Khoronzhuk
Sent: Monday, November 23, 2015 11:21 PM
To: lng-odp@lists.linaro.org
Subject: [lng-odp] [API-NEXT PATCH v3 6/7] api: time: make odp_local_time
to be monotonic wall time

It's more convenient the local time to be a monotonic wall time.
That means time starts from 0 and not wraps. It allows to use local
time in similar manner as it's supposed to be used with global time
and the 64-bit timer is enough to guarantee it.

Signed-off-by: Ivan Khoronzhuk 






diff --git a/include/odp/api/time.h b/include/odp/api/time.h
index 50a0bf5..9865d81 100644
--- a/include/odp/api/time.h
+++ b/include/odp/api/time.h
@@ -45,7 +45,8 @@ extern "C" {
   * Current local time
   *
   * Returns current local time stamp value. The local time source provides
high
- * resolution time.
+ * resolution time, it is initialized to zero during ODP startup and will
not
+ * wrap around in at least 10 years.
   *
   * @return Local time stamp.
   */



I think it's better to separate this the API spec into its own patch. All other 
changes here may or may not depend on it, but those can follow in the next 
patch. It's significant spec change and an implementer may miss it now.


Ok. I will split it on linux-generic + api and examples/testes patches.
But I think this simplification is not very eficient as api change patch will 
contain:
 include/odp/api/time.h|  3 +-
 platform/linux-generic/include/odp_internal.h |  2 +
 platform/linux-generic/odp_schedule.c |  9 ++--
 platform/linux-generic/odp_time.c | 61 +++

and example/test patch:
 example/generator/odp_generator.c | 10 ++---
 test/performance/odp_pktio_perf.c | 26 ++--
 test/validation/pktio/pktio.c | 21 -



-Petri








--
Regards,
Ivan Khoronzhuk
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp


Re: [lng-odp] [API-NEXT PATCH v3 7/7] validation: time: align tests with current time API

2015-11-30 Thread Savolainen, Petri (Nokia - FI/Espoo)


> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
> Ivan Khoronzhuk
> Sent: Monday, November 23, 2015 11:21 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [API-NEXT PATCH v3 7/7] validation: time: align tests
> with current time API
> 
> Add test for odp_time_sum, odp_time_cmp, odp_time_to_u64 APIs.
> Sophisticate a little tests for odp_time_diff, odp_time_local_from_ns,
> odp_time_local_to_ns APIs. Check time on monotony.
> 
> Signed-off-by: Ivan Khoronzhuk 
> ---
>  test/validation/time/time.c | 224
> +++-
>  test/validation/time/time.h |   7 +-
>  2 files changed, 207 insertions(+), 24 deletions(-)
> 
> diff --git a/test/validation/time/time.c b/test/validation/time/time.c
> index 3d05a6f..8f5dfe6 100644
> --- a/test/validation/time/time.c
> +++ b/test/validation/time/time.c
> @@ -11,13 +11,114 @@
>  #define TOLERANCE 1
>  #define BUSY_LOOP_CNT 100
> 
> +/* check that related conversions come back to the same value */
> +void time_test_odp_conversion(void)
> +{
> + uint64_t ns1, ns2;
> + odp_time_t time;
> + uint64_t upper_limit, lower_limit;
> +
> + ns1 = 100;
> + time = odp_time_local_from_ns(ns1);
> +
> + ns2 = odp_time_to_ns(time);
> +
> + /* need to check within arithmetic tolerance that the same
> +  * value in ns is returned after conversions */
> + upper_limit = ns1 + TOLERANCE;
> + lower_limit = ns1 - TOLERANCE;
> + CU_ASSERT((ns2 <= upper_limit) && (ns2 >= lower_limit));
> +
> + ns1 = 60 * 11 * ODP_TIME_SEC_IN_NS;
> + time = odp_time_local_from_ns(ns1);
> +
> + ns2 = odp_time_to_ns(time);
> +
> + /* need to check within arithmetic tolerance that the same
> +  * value in ns is returned after conversions */
> + upper_limit = ns1 + TOLERANCE;
> + lower_limit = ns1 - TOLERANCE;
> + CU_ASSERT((ns2 <= upper_limit) && (ns2 >= lower_limit));
> +}
> +
> +void time_test_monotony(void)
> +{
> + volatile int count = 0;
> + odp_time_t t1, t2, t3;
> + uint64_t ns1, ns2, ns3;
> +
> + t1 = odp_time_local();
> +
> + while (count < BUSY_LOOP_CNT) {
> + count++;
> + };
> +
> + t2 = odp_time_local();
> +
> + while (count < BUSY_LOOP_CNT * 5) {
> + count++;
> + };
> +
> + t3 = odp_time_local();


These loops are short in execution time. So, the test will very likely to pass 
also when local time would wrap e.g. every 4 sec.

At least one test should run at least e.g. 4sec to verify wrap around.

-Petri
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp


Re: [lng-odp] [API-NEXT PATCH v3 7/7] validation: time: align tests with current time API

2015-11-30 Thread Ivan Khoronzhuk



On 30.11.15 16:17, Savolainen, Petri (Nokia - FI/Espoo) wrote:




-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of EXT
Ivan Khoronzhuk
Sent: Monday, November 23, 2015 11:21 PM
To: lng-odp@lists.linaro.org
Subject: [lng-odp] [API-NEXT PATCH v3 7/7] validation: time: align tests
with current time API

Add test for odp_time_sum, odp_time_cmp, odp_time_to_u64 APIs.
Sophisticate a little tests for odp_time_diff, odp_time_local_from_ns,
odp_time_local_to_ns APIs. Check time on monotony.

Signed-off-by: Ivan Khoronzhuk 
---
  test/validation/time/time.c | 224
+++-
  test/validation/time/time.h |   7 +-
  2 files changed, 207 insertions(+), 24 deletions(-)

diff --git a/test/validation/time/time.c b/test/validation/time/time.c
index 3d05a6f..8f5dfe6 100644
--- a/test/validation/time/time.c
+++ b/test/validation/time/time.c
@@ -11,13 +11,114 @@
  #define TOLERANCE 1
  #define BUSY_LOOP_CNT 100

+/* check that related conversions come back to the same value */
+void time_test_odp_conversion(void)
+{
+   uint64_t ns1, ns2;
+   odp_time_t time;
+   uint64_t upper_limit, lower_limit;
+
+   ns1 = 100;
+   time = odp_time_local_from_ns(ns1);
+
+   ns2 = odp_time_to_ns(time);
+
+   /* need to check within arithmetic tolerance that the same
+* value in ns is returned after conversions */
+   upper_limit = ns1 + TOLERANCE;
+   lower_limit = ns1 - TOLERANCE;
+   CU_ASSERT((ns2 <= upper_limit) && (ns2 >= lower_limit));
+
+   ns1 = 60 * 11 * ODP_TIME_SEC_IN_NS;
+   time = odp_time_local_from_ns(ns1);
+
+   ns2 = odp_time_to_ns(time);
+
+   /* need to check within arithmetic tolerance that the same
+* value in ns is returned after conversions */
+   upper_limit = ns1 + TOLERANCE;
+   lower_limit = ns1 - TOLERANCE;
+   CU_ASSERT((ns2 <= upper_limit) && (ns2 >= lower_limit));
+}
+
+void time_test_monotony(void)
+{
+   volatile int count = 0;
+   odp_time_t t1, t2, t3;
+   uint64_t ns1, ns2, ns3;
+
+   t1 = odp_time_local();
+
+   while (count < BUSY_LOOP_CNT) {
+   count++;
+   };
+
+   t2 = odp_time_local();
+
+   while (count < BUSY_LOOP_CNT * 5) {
+   count++;
+   };
+
+   t3 = odp_time_local();



These loops are short in execution time. So, the test will very likely to pass 
also when local time would wrap e.g. every 4 sec.

I can increase BUSY_LOOP_CNT, replace 100 number that is based on some freq 
like 3GHz and minimum resolution.
The resolution API I'm going to add after this series is applied, so for now 
lets suppose that this is 10ms.

then BYSY_LOOP_CNT for testing minimum time is = 0.01 * 3GHz = 3000.
For some boards it can take in 3 times longer.




At least one test should run at least e.g. 4sec to verify wrap around.

I don't suppose here that 32-bit counter is used for time API, so check is 
redundancy. But,
for long time intervals I've used conversion functions, it's checked in 
time_test_conversion test.
It's done in order to not increase time for validating time API.
If you OK to increase validation test for time API at least on 5sec I have no 
objection.

Currently ODP doesn't have correct way to read frequency for all arches.
So lets count 4seconds based on some freq = 3GHz, then iteration_num = 4sec * 
3000 = 12 000 000 000.
It's bigger than 4seconds as iteration takes more than one simple cycle.
Then:
BUSY_LOOP_CNT = 1000, and test for time more that 4 sec => BUSY_LOOP_CNT = 1000 
* 12.

But pay attention, that it can take more than 4sec * 3 * 2cycles = 24 seconds 
on boards with 3 time less frequency.
So test can be longer on half of minute!.

I propose to leave test as is here, and hope that time_test_odp_conversion 
caught issues.
What do you say?
 


-Petri



--
Regards,
Ivan Khoronzhuk
___
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp