Re: [lng-odp] [PATCHv4 5/5] api: config: simplify packet configuration

[Savolainen, Petri (NSN - FI/Espoo)]

Entire patch set

Reviewed-by: Petri Savolainen 


> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Bill Fischofer
> Sent: Thursday, February 19, 2015 3:38 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv4 5/5] api: config: simplify packet
> configuration
> 
> Remove headroom/tailroom from ODP_CONFIG_PACKET_SEG_LEN_MIN and
> clarify meaning of ODP_CONFIG_PACKET_SEG_LEN_MAX.
> 
> Signed-off-by: Bill Fischofer 
> ---
>  include/odp/api/config.h | 12 ++--
>  1 file changed, 2 insertions(+), 10 deletions(-)
> 
> diff --git a/include/odp/api/config.h b/include/odp/api/config.h
> index 3ac9e2c..c15d340 100644
> --- a/include/odp/api/config.h
> +++ b/include/odp/api/config.h
> @@ -95,15 +95,8 @@ extern "C" {
>   * This defines the minimum packet segment buffer length in bytes. The
> user
>   * defined segment length (seg_len in odp_pool_param_t) will be rounded
> up into
>   * this value.
> - *
> - * @internal In linux-generic implementation:
> - * - The value MUST be a multiple of 8.
> - * - The value MUST be a multiple of ODP_CACHE_LINE_SIZE
> - * - The default value (1664) is large enough to support 1536-byte
> packets
> - *   with the default headroom shown above and is a multiple of both 64
> and 128,
> - *   which are the most common cache line sizes.
>   */
> -#define ODP_CONFIG_PACKET_SEG_LEN_MIN (1664)
> +#define ODP_CONFIG_PACKET_SEG_LEN_MIN (1598)
> 
>  /**
>   * Maximum packet segment length
> @@ -111,9 +104,8 @@ extern "C" {
>   * This defines the maximum packet segment buffer length in bytes. The
> user
>   * defined segment length (seg_len in odp_pool_param_t) must not be
> larger than
>   * this.
> - *
>   */
> -#define ODP_CONFIG_PACKET_SEG_LEN_MAX ODP_CONFIG_PACKET_SEG_LEN_MIN
> +#define ODP_CONFIG_PACKET_SEG_LEN_MAX (64*1024)
> 
>  /**
>   * Maximum packet buffer length
> --
> 2.1.0
> 
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp

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

Re: [lng-odp] [PATCH v2 00/10] add global and local termination

[Savolainen, Petri (NSN - FI/Espoo)]

It's OK to do that. Also since it's implementation, you can exploit the fact 
that shm_free catches SHM_INVALID and returns -1 (== defined behavior). 

It would be cleaner/faster to save handles and use those, but not that 
important since termination is not performance critical.

-Petri

> -Original Message-
> From: ext Robbie King (robking) [mailto:robk...@cisco.com]
> Sent: Wednesday, February 18, 2015 6:50 PM
> To: Taras Kondratiuk
> Cc: Mike Holmes; lng-odp@lists.linaro.org; Petri Savolainen
> (petri.savolai...@linaro.org)
> Subject: RE: [lng-odp] [PATCH v2 00/10] add global and local termination
> 
> While I'm not a big fan of the "lookup" APIs myself, if
> they exist implementations should be able to use them I think.
> 
> Does the nesting violate any coding style restrictions?
> 
>ret = odp_shm_free(odp_shm_lookup("shm_odp_cos_tbl"));
> 
> 
> -Original Message-
> From: Taras Kondratiuk [mailto:taras.kondrat...@linaro.org]
> Sent: Wednesday, February 18, 2015 11:01 AM
> To: Robbie King (robking)
> Cc: Mike Holmes; lng-odp@lists.linaro.org; Petri Savolainen
> (petri.savolai...@linaro.org)
> Subject: Re: [lng-odp] [PATCH v2 00/10] add global and local termination
> 
> On 02/18/2015 05:53 PM, Robbie King (robking) wrote:
> > Hey Mike (and everyone else),
> >
> > I noticed this code is replicated throughout the patch:
> >
> > cos_shm = odp_shm_lookup("shm_odp_cos_tbl");
> > if (cos_shm == ODP_SHM_INVALID)
> > return -1;
> > ret = odp_shm_free(cos_shm);
> >
> > As I was looking to make the changes we discussed (continue
> > on versus returning -1) it seemed instead of replicating
> > even more code it would be better to have some cleaner way
> > of doing this.
> >
> > One possibility is to simply nest the calls (shm_free just
> > returns -1 if passed SHM_INVALID).
> >
> >ret = odp_shm_free(odp_shm_lookup("shm_odp_cos_tbl"));
> >
> > Another option is to create a helper function, something like:
> >
> >ret = odp_shm_free_by_name("shm_odp_cos_tbl");
> >
> > If the helper is the way to go, then it could either be internal
> > or published API.  Any thoughts on the "correct solution"?
> >
> > 1) nested calls
> > 2) internal API
> > 3) published API
> 
> I prefer a forth option :)
> Save allocated odp_shm_t handle and don't lookup it.
___
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCHv3 5/5] api: config: simplify packet configuration

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Bill Fischofer
> Sent: Wednesday, February 18, 2015 10:03 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv3 5/5] api: config: simplify packet
> configuration
> 
> Remove headroom/tailroom from ODP_CONFIG_PACKET_SEG_LEN_MIN and
> clarify meaning of ODP_CONFIG_PACKET_SEG_LEN_MAX.
> 
> Signed-off-by: Bill Fischofer 
> ---
>  include/odp/api/config.h | 14 +++---
>  1 file changed, 3 insertions(+), 11 deletions(-)
> 
> diff --git a/include/odp/api/config.h b/include/odp/api/config.h
> index 3ac9e2c..5f211f3 100644
> --- a/include/odp/api/config.h
> +++ b/include/odp/api/config.h
> @@ -95,25 +95,17 @@ extern "C" {
>   * This defines the minimum packet segment buffer length in bytes. The
> user
>   * defined segment length (seg_len in odp_pool_param_t) will be rounded
> up into
>   * this value.
> - *
> - * @internal In linux-generic implementation:
> - * - The value MUST be a multiple of 8.
> - * - The value MUST be a multiple of ODP_CACHE_LINE_SIZE
> - * - The default value (1664) is large enough to support 1536-byte
> packets
> - *   with the default headroom shown above and is a multiple of both 64
> and 128,
> - *   which are the most common cache line sizes.
>   */
> -#define ODP_CONFIG_PACKET_SEG_LEN_MIN (1664)
> +#define ODP_CONFIG_PACKET_SEG_LEN_MIN (1598)
> 
>  /**
>   * Maximum packet segment length
>   *
>   * This defines the maximum packet segment buffer length in bytes. The
> user
>   * defined segment length (seg_len in odp_pool_param_t) must not be
> larger than
> - * this.
> - *
> + * this. A value of 0 indicates no upper limit.
>   */
> -#define ODP_CONFIG_PACKET_SEG_LEN_MAX ODP_CONFIG_PACKET_SEG_LEN_MIN
> +#define ODP_CONFIG_PACKET_SEG_LEN_MAX 0

0 doesn't work here since user may want to compare,

if (my_seg_len < _SEG_LEN_MAX)
...
else
...

OR substitute it (use always max seg len)

params.pkt.seg_len = _SEG_LEN_MAX;


So, it's better to pick a reasonable max number, e.g. 64 kB which would already 
fit the largest possible UDP datagram (16 bit length) into a single segment.


Patches 1-4 are OK.


-Petri


> 
>  /**
>   * Maximum packet buffer length
> --
> 2.1.0
> 
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp

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

Re: [lng-odp] [PATCHv2 3/4] api: pools: normalize odp_pool_param_t layout

[Savolainen, Petri (NSN - FI/Espoo)]

Structure alignment and padding is compiler specific. I remember seeing 
compiler aligning all structs into 8-byte alignment, also when all members are 
<8 bytes.

-Petri



From: ext Bill Fischofer [mailto:bill.fischo...@linaro.org]
Sent: Tuesday, February 17, 2015 8:44 PM
To: Savolainen, Petri (NSN - FI/Espoo)
Cc: lng-odp@lists.linaro.org
Subject: Re: [lng-odp] [PATCHv2 3/4] api: pools: normalize odp_pool_param_t 
layout

V1 had it this way but I changed that in V2 to put type first as the rest is a 
variable-length structure (depending on type) so it seemed to make more sense 
to have the key for decoding the rest first.  Alignment is not an issue here.  
It's not a "may have" since the actual structure layouts we're defining here 
are part of the ODP API and are not subject to per-implementation differences.

On Tue, Feb 17, 2015 at 7:32 PM, Savolainen, Petri (NSN - FI/Espoo) 
mailto:petri.savolai...@nsn.com>> wrote:


> -Original Message-
> From: 
> lng-odp-boun...@lists.linaro.org<mailto:lng-odp-boun...@lists.linaro.org> 
> [mailto:lng-odp-<mailto:lng-odp->
> boun...@lists.linaro.org<mailto:boun...@lists.linaro.org>] On Behalf Of ext 
> Bill Fischofer
> Sent: Saturday, February 14, 2015 1:14 AM
> To: lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org>
> Subject: [lng-odp] [PATCHv2 3/4] api: pools: normalize odp_pool_param_t
> layout
>
> Signed-off-by: Bill Fischofer 
> mailto:bill.fischo...@linaro.org>>
> ---
>  include/odp/api/pool.h | 24 +---
>  1 file changed, 9 insertions(+), 15 deletions(-)
>
> diff --git a/include/odp/api/pool.h b/include/odp/api/pool.h
> index 66dc70e..b15ddd5 100644
> --- a/include/odp/api/pool.h
> +++ b/include/odp/api/pool.h
> @@ -47,8 +47,10 @@ extern "C" {
>   * Used to communicate pool creation options.
>   */
>  typedef struct odp_pool_param_t {
> + int type;  /**< Pool type */

A minor thing. I'd keep "type" after the union in this struct. The
union may have larger alignment requirement than int (depending on compiler)
and in that case would force padding here (between int and union).

Otherwise OK.

-Petri


>   union {
>   struct {
> + uint32_t num;   /**< Number of buffers in the pool */
>   uint32_t size;  /**< Buffer size in bytes.  The
>maximum number of bytes
>application will store in each
> @@ -58,20 +60,11 @@ typedef struct odp_pool_param_t {
>Use 0 for default alignment.
>Default will always be a multiple
>of 8. */
> - uint32_t num;   /**< Number of buffers in the pool */
>   } buf;
>   struct {
> - uint32_t seg_len;   /**< Minimum number of packet data
> -  bytes that are stored in the
> -  first segment of a packet.
> -  The maximum value is defined by
> -  ODP_CONFIG_PACKET_SEG_LEN_MAX.
> -  Use 0 for default. */
> - uint32_t __res1;/* Keep struct identical to buf,
> -until implementation is fixed */
>   uint32_t num;   /**< The number of packets that the
>pool must provide that are
> -  packet lenght 'len' bytes or
> +  packet length 'len' bytes or
>smaller. */
>   uint32_t len;   /**< Minimum packet length that the
>pool must provide 'num'
> @@ -80,16 +73,17 @@ typedef struct odp_pool_param_t {
>packets are larger than 'len'.
>Use 0 for default.
>*/
> + uint32_t seg_len;   /**< Minimum number of packet data
> +  bytes that are stored in the
> +  first segment of a packet.
> +  The maximum value is defined by
> +  ODP_CONFIG_PACKET_SEG_LEN_MAX.
> +  

Re: [lng-odp] [PATCHv2 4/4] linux-generic: pools: cleanup to reflect new pool parameters

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Bill Fischofer
> Sent: Saturday, February 14, 2015 1:14 AM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv2 4/4] linux-generic: pools: cleanup to reflect
> new pool parameters
> 
> Signed-off-by: Bill Fischofer 
> ---
>  platform/linux-generic/include/odp_pool_internal.h |  1 +
>  platform/linux-generic/odp_pool.c  | 66 +++--
> -
>  2 files changed, 34 insertions(+), 33 deletions(-)
> 
> diff --git a/platform/linux-generic/include/odp_pool_internal.h
> b/platform/linux-generic/include/odp_pool_internal.h
> index c5354e5..0c0c0be 100644
> --- a/platform/linux-generic/include/odp_pool_internal.h
> +++ b/platform/linux-generic/include/odp_pool_internal.h
> @@ -119,6 +119,7 @@ struct pool_entry_s {
>   odp_atomic_u64_tblkempty;
>   odp_atomic_u64_thigh_wm_count;
>   odp_atomic_u64_tlow_wm_count;
> + uint32_tbuf_num;
>   uint32_tseg_size;
>   uint32_thigh_wm;
>   uint32_tlow_wm;
> diff --git a/platform/linux-generic/odp_pool.c b/platform/linux-
> generic/odp_pool.c
> index c07392f..1fe0c5f 100644
> --- a/platform/linux-generic/odp_pool.c
> +++ b/platform/linux-generic/odp_pool.c
> @@ -136,13 +136,9 @@ odp_pool_t odp_pool_create(const char *name,
>   ODP_CACHE_LINE_SIZE_ROUNDUP(init_params->udata_size) :
>   0;
> 
> - uint32_t blk_size, buf_stride;
> - uint32_t buf_align;
> -
> - if (params->type == ODP_POOL_PACKET)
> - buf_align = 0;
> - else
> - buf_align = params->buf.align;
> + uint32_t blk_size, buf_stride, buf_num;
> + uint32_t buf_align =
> + params->type == ODP_POOL_BUFFER ? params->buf.align : 0;
> 
>   /* Validate requested buffer alignment */
>   if (buf_align > ODP_CONFIG_BUFFER_ALIGN_MAX ||
> @@ -158,35 +154,41 @@ odp_pool_t odp_pool_create(const char *name,
>   /* Calculate space needed for buffer blocks and metadata */
>   switch (params->type) {
>   case ODP_POOL_BUFFER:
> - case ODP_POOL_TIMEOUT:
> + buf_num  = params->buf.num;
>   blk_size = params->buf.size;
> 
>   /* Optimize small raw buffers */
>   if (blk_size > ODP_MAX_INLINE_BUF || params->buf.align != 0)
>   blk_size = ODP_ALIGN_ROUNDUP(blk_size, buf_align);
> 
> - buf_stride = params->type == ODP_POOL_BUFFER ?
> - sizeof(odp_buffer_hdr_stride) :
> - sizeof(odp_timeout_hdr_stride);
> + buf_stride = sizeof(odp_buffer_hdr_stride);
>   break;
> 
>   case ODP_POOL_PACKET:
>   headroom = ODP_CONFIG_PACKET_HEADROOM;
>   tailroom = ODP_CONFIG_PACKET_TAILROOM;
> - unseg = params->pkt.seg_len > ODP_CONFIG_PACKET_BUF_LEN_MAX;
> + buf_num = params->pkt.num;
> + uint32_t seg_len = params->pkt.seg_len == 0 ?
> + ODP_CONFIG_PACKET_SEG_LEN_MIN :

Similar to the next line, this needs headroom/tailroom added. In other words,

if (params->pkt.seg_len == 0)
params->pkt.seg_len = ODP_CONFIG_PACKET_SEG_LEN_MIN;


> + headroom + params->pkt.seg_len + tailroom;
> + uint32_t pkt_len = params->pkt.len <= seg_len ?
> + seg_len : params->pkt.len;
> + unseg = pkt_len > ODP_CONFIG_PACKET_BUF_LEN_MAX;

ODP_CONFIG_PACKET_BUF_LEN_MAX defines the absolute maximum number of bytes that 
can be stored into a packet (over all segments). The pool create should fail if 
pkt_len (+headroom+tailroom) > ODP_CONFIG_PACKET_BUF_LEN_MAX.

With this code, "unseg" would be true if params->pkt.len or params->pkt.seg_len 
> 6 * 1664 ??

> 
>   if (unseg)
> - blk_size = ODP_ALIGN_ROUNDUP(
> - headroom + params->pkt.seg_len + tailroom,
> - buf_align);
> + blk_size = ODP_ALIGN_ROUNDUP(seg_len,
> + ODP_CONFIG_BUFFER_ALIGN_MIN);
>   else
> - blk_size = ODP_ALIGN_ROUNDUP(
> - headroom + params->pkt.seg_len + tailroom,
> + blk_size = ODP_ALIGN_ROUNDUP(pkt_len,
>   ODP_CONFIG_PACKET_SEG_LEN_MIN);


Not sure if the unseg logic above makes sense. Would it be easier to consider 
all packets "segmented". Depending on packet data length and pool setup, most 
or even all packets in the pool could have only one segment.

-Petri


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

Re: [lng-odp] [PATCHv2 3/4] api: pools: normalize odp_pool_param_t layout

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Bill Fischofer
> Sent: Saturday, February 14, 2015 1:14 AM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv2 3/4] api: pools: normalize odp_pool_param_t
> layout
> 
> Signed-off-by: Bill Fischofer 
> ---
>  include/odp/api/pool.h | 24 +---
>  1 file changed, 9 insertions(+), 15 deletions(-)
> 
> diff --git a/include/odp/api/pool.h b/include/odp/api/pool.h
> index 66dc70e..b15ddd5 100644
> --- a/include/odp/api/pool.h
> +++ b/include/odp/api/pool.h
> @@ -47,8 +47,10 @@ extern "C" {
>   * Used to communicate pool creation options.
>   */
>  typedef struct odp_pool_param_t {
> + int type;  /**< Pool type */

A minor thing. I'd keep "type" after the union in this struct. The 
union may have larger alignment requirement than int (depending on compiler) 
and in that case would force padding here (between int and union).

Otherwise OK.

-Petri


>   union {
>   struct {
> + uint32_t num;   /**< Number of buffers in the pool */
>   uint32_t size;  /**< Buffer size in bytes.  The
>maximum number of bytes
>application will store in each
> @@ -58,20 +60,11 @@ typedef struct odp_pool_param_t {
>Use 0 for default alignment.
>Default will always be a multiple
>of 8. */
> - uint32_t num;   /**< Number of buffers in the pool */
>   } buf;
>   struct {
> - uint32_t seg_len;   /**< Minimum number of packet data
> -  bytes that are stored in the
> -  first segment of a packet.
> -  The maximum value is defined by
> -  ODP_CONFIG_PACKET_SEG_LEN_MAX.
> -  Use 0 for default. */
> - uint32_t __res1;/* Keep struct identical to buf,
> -until implementation is fixed */
>   uint32_t num;   /**< The number of packets that the
>pool must provide that are
> -  packet lenght 'len' bytes or
> +  packet length 'len' bytes or
>smaller. */
>   uint32_t len;   /**< Minimum packet length that the
>pool must provide 'num'
> @@ -80,16 +73,17 @@ typedef struct odp_pool_param_t {
>packets are larger than 'len'.
>Use 0 for default.
>*/
> + uint32_t seg_len;   /**< Minimum number of packet data
> +  bytes that are stored in the
> +  first segment of a packet.
> +  The maximum value is defined by
> +  ODP_CONFIG_PACKET_SEG_LEN_MAX.
> +  Use 0 for default. */
>   } pkt;
>   struct {
> - uint32_t __res1; /* Keep struct identical to buf, */
> - uint32_t __res2; /* until pool implementation is fixed*/
>   uint32_t num;/**< Number of timeouts in the pool */
>   } tmo;
>   };
> -
> - int type;  /**< Pool type */
> -
>  } odp_pool_param_t;
> 
>  /** Packet pool*/
> --
> 2.1.0
> 
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp

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

Re: [lng-odp] [PATCHv2 1/4] linux-generic: pools: rename odp_buffer_pool files to odp_pool

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Bill Fischofer
> Sent: Saturday, February 14, 2015 1:14 AM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv2 1/4] linux-generic: pools: rename
> odp_buffer_pool files to odp_pool
> 
> Signed-off-by: Bill Fischofer 
> ---

> +++ b/platform/linux-generic/include/odp_pool_internal.h
> @@ -0,0 +1,380 @@
> +/* Copyright (c) 2013, Linaro Limited
> + * All rights reserved.
> + *
> + * SPDX-License-Identifier: BSD-3-Clause
> + */
> +
> +
> +/**
> + * @file
> + *
> + * ODP buffer pool - internal header
> + */
> +
> +#ifndef ODP_BUFFER_POOL_INTERNAL_H_
> +#define ODP_BUFFER_POOL_INTERNAL_H_

It should be now ODP_POOL_INTERNAL_H_


-Petri



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

Re: [lng-odp] [PATCH 1/2] api: scheduler: atomic and ordered definitions

[Savolainen, Petri (NSN - FI/Espoo)]

It's going to be only this patch 1/2. There's no 2/2 (for API 1.0).

-Petri


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

Re: [lng-odp] [PATCH v3 3/3] api: config: Renamed ODP_CONFIG_PACKET_BUF_LEN_MIN

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: ext Ola Liljedahl [mailto:ola.liljed...@linaro.org]
> Sent: Monday, February 16, 2015 10:29 AM
> To: Petri Savolainen
> Cc: LNG ODP Mailman List
> Subject: Re: [lng-odp] [PATCH v3 3/3] api: config: Renamed
> ODP_CONFIG_PACKET_BUF_LEN_MIN
> 
> On 13 February 2015 at 04:32, Petri Savolainen
>  wrote:
> > Renamed ODP_CONFIG_PACKET_BUF_LEN_MIN to ODP_CONFIG_PACKET_SEG_LEN_MIN.
> > The packet pool parameter pkt.seg_len is rounded up into this value.
> >
> > Added ODP_CONFIG_PACKET_SEG_LEN_MAX to define the maximum segment
> > length supported by the implementation. This is the maximum valid
> > value for pkt.seg_len.
> >
> > If ODP_CONFIG_PACKET_SEG_LEN_MIN equals _SEG_LEN_MAX, the
> > implementation supports only one segment length value.
> As I have voiced before, I think config.h is a weird beast. Is it an
> output from the ODP implementation? Is it an input to the ODP
> implementation should it be recompiled? Is it both? Which config items
> can be changed by the user? Why are there references to linux-generic
> in the current config.h?


The config API (ODP_CONFIG_XXX) provides standard configuration options for the 
application. All values are implementation specific. An implementation 
specifies default values, and should document the valid/recommended range of 
values (in README or doxygen documentation). An application can change values 
(within these limits) to adapt/optimize the implementation for its use case.

For example, if implementation support 128 ... 100 Million queues and the  
default is 1 Million, an application may change ODP_CONFIG_QUEUES to 1k, if it 
needs never more queues than that. Implementation can use that (compile time)  
information to optimize its memory usage and algorithms for 1k queues (instead 
of millions of queues).

The public API file should define only doxygen API documentation. The #define 
and additional implementation specific limits (like those linux-generic notes) 
should be defined in an implementation specific file. Originally config.h was 
implementation specific (as all other API headers). The directory restructure 
work (generic API vs. implementation specific) is still ongoing here.

- Petri


> 
> When all of these questions arise, something is fishy.
> 
> Let's look ahead. ODP is installed as a development library (e.g. deb
> package libodp-dev), possibly with a well-defined ABI. Applications
> might be dynamically linked to some target-specific ODP
> implementation. How does the application get to know about internal
> limitations in the actual ODP implementation (e.g. max number of
> shared memory segments or maximum packet size)? By calling an API at
> run-time which returns the requested value. What happens if the
> application requests something (e.g. too large segment or packet size)
> which cannot be supported by the implementation? The relevant API
> (e.g. create_pool) returns a well-defined error.
> 
> No need for elaborate computations in the application in order to
> satisfy implementation specific limitations.
> 
> -- Ola
> 
> >
> > Signed-off-by: Petri Savolainen 
> > ---
> >  include/odp/api/config.h | 20
> +++-
> >  platform/linux-generic/include/odp_buffer_internal.h | 12 ++--
> >  platform/linux-generic/odp_buffer_pool.c |  4 ++--
> >  test/validation/buffer/odp_packet_test.c |  2 +-
> >  4 files changed, 24 insertions(+), 14 deletions(-)
> >
> > diff --git a/include/odp/api/config.h b/include/odp/api/config.h
> > index bd69b98..3ac9e2c 100644
> > --- a/include/odp/api/config.h
> > +++ b/include/odp/api/config.h
> > @@ -92,9 +92,9 @@ extern "C" {
> >  /**
> >   * Minimum packet segment length
> >   *
> > - * This defines the minimum packet segment length in bytes. The user
> defined
> > - * buffer size (in odp_buffer_pool_param_t) in buffer pool creation
> will be
> > - * rounded up into this value.
> > + * This defines the minimum packet segment buffer length in bytes. The
> user
> > + * defined segment length (seg_len in odp_pool_param_t) will be rounded
> up into
> > + * this value.
> >   *
> >   * @internal In linux-generic implementation:
> >   * - The value MUST be a multiple of 8.
> > @@ -103,7 +103,17 @@ extern "C" {
> >   *   with the default headroom shown above and is a multiple of both 64
> and 128,
> >   *   which are the most common cache line sizes.
> >   */
> > -#define ODP_CONFIG_PACKET_BUF_LEN_MIN (1664)
> > +#define ODP_CONFIG_PACKET_SEG_LEN_MIN (1664)
> > +
> > +/**
> > + * Maximum packet segment length
> > + *
> > + * This defines the maximum packet segment buffer length in bytes. The
> user
> > + * defined segment length (seg_len in odp_pool_param_t) must not be
> larger than
> > + * this.
> > + *
> > + */
> > +#define ODP_CONFIG_PACKET_SEG_LEN_MAX ODP_CONFIG_PACKET_SEG_LEN_MIN
> >
> >  /**
> >   * Maximum packet buffer length
> > @@ -117,7 +127,7 @@ extern "C" {
> >   * - The value MUST be an integral n

Re: [lng-odp] [PATCH v2 1/3] api: pool: Added packet pool parameters

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: ext Ola Liljedahl [mailto:ola.liljed...@linaro.org]
> Sent: Tuesday, February 03, 2015 11:05 PM
> To: Petri Savolainen
> Cc: LNG ODP Mailman List
> Subject: Re: [lng-odp] [PATCH v2 1/3] api: pool: Added packet pool
> parameters
> 
> My alternative approach that should achieve that same goals as Petri
> but give more freedom to implementations. You don't have to approve of
> it, I just want to show that given a defined and understood problem,
> many potential solutions exist and the first alternative might not be
> the best. Let's work together.

I think your proposal is not substantially different what I have suggested 
already (including conf calls). Main difference is that 1st segment vs other 
segments configuration would be introduced already in v1.0. I was thinking to 
nail v1.0 with minimum support (keep it close to what we have already done) and 
extend from there (with concept of 1st/other segments). 


> 
> * init_seg_len:
> On input: user's required (desired) minimal length of initial
> segment (including headroom)
> On output: implementation's best effort to match user's request
> Purpose: ensure that those packet headers the application
> normally will process are stored in a consecutive memory area.
> Applications do not have to check any configuration in order
> to initialize a configuration which the implementation anyway has to
> check if it can support.
> Applications should check output values to see if its desired
> values were matched. The application decides whether a failure to
> match is a fatal error or the application can handle the situation
> anyway (e.g. with degraded performance because it has to do some
> workarounds in SW).

This would be .first_seg_len. Application is not interested on the actual len, 
either implementation can support the minimum requirement or not. That's why 
output param is not necessary, but min/max limits are needed. Limits can be 
provided as macros or function calls.

I'd postpone splitting .seg_len from current proposal to .first_seg_len and 
.other_seg_len some time after v1.0 when we continue packet API segmentation 
API development anyway.

> 
> * seg_len:
> On input: user's desired length of other segments
> On output: implementation's best effort to match user's request
> Purpose: a hint from the user how to partition to pool into
> segments for best trade-off between memory utilization and SW
> processing performance.
> Note: I know some HW can support multiple segment sizes so I
> think it is useful for the API to allow for this. Targets which only
> support one segment size (per packet pool) could use e.g.
> max(int_seg_len, seg_len). Some targets may not allow user-defined
> segment sizes at all, the ODP implementation will just return the
> actual values and the application can check whether those are
> acceptable.

This would be .other_seg_len. This can be hint vs 1st seg len is strict 
requirement.

> 
> * init_seg_num:
>On input: Number of initial segments.
>On output: Updated with actual number of segments if a shared
> memory region was specified?

This is also max number of packets (== seg_num in my proposal). Again I 
considered to postpone the split of first_seg_num/packet_num and other_seg_num 
after v1.0.

Application may want (usually does) to specify max number of packet as hard 
limit, since that's the limit for maximum number of in-flight packet inside 
your app / SoC. The limit is  needed for QoS, per packet context memory 
allocation, etc.

It depends on application if actual number is interesting or only 
success/failure.


> * seg_num:
> On input: Number of other segments.
>On output: Updated with actual number of segments if a shared
> memory region was specified?
> 
> I dislike the defines because they will make a future portable ABI
> (binary interface) definition impossible. We will need a portable ABI
> to support e.g. shared library implementations. So all ODP_CONFIG's
> should only be used internally (by the implementation in question) and
> not be accessible as compile time constants to applications, i.e. they
> should not be part of the ODP API. Are there any other instances where
> the application is supposed to use these constants?

This a new requirement, and is probably a valid one also. Obviously, any config 
interface development need to be postponed after v1.0.

Since v1.0 has ODP_CONFIG_XXX (config.h) in the API, it's possible to use that 
mechanism also for these limits. Functions could be used also, but it would not 
solve the config issue as have used ODP_CONFIG_XXX already for other things 
like buffers. Minimizing changes to current practices to reach v1.0 sooner than 
later...


-Petri 


> 
> -- Ola
> 
> On 3 February 2015 at 14:31, Ola Liljedahl 
> wrote:
> > On 3 February 2015 at 13:59, Petri Savolainen
> >  wrote:
> >> Completed odp_pool_param_t definitio

Re: [lng-odp] [PATCHv2] api: reflect file path in header guards

[Savolainen, Petri (NSN - FI/Espoo)]

This is OK to merge.

Reviewed-by: Petri Savolainen 


> --- a/include/odp/api/classification.h
> +++ b/include/odp/api/classification.h
> @@ -11,8 +11,8 @@
>   * ODP classification descriptor
>   */
> 
> -#ifndef ODP_CLASSIFY_H_
> -#define ODP_CLASSIFY_H_
> +#ifndef ODP_API_CLASSIFY_H_
> +#define ODP_API_CLASSIFY_H_

#define ODP_API_CLASSIFICATION_H_

That and potentially other .h file guard names (check all .h files in the repo) 
should be corrected also in another patch.


-Petri


> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Taras Kondratiuk
> Sent: Thursday, February 05, 2015 7:58 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv2] api: reflect file path in header guards
> 
> Start header guards with ODP_API_ prefix to avoid confusion with other
> files with the same name.
> 
> Signed-off-by: Taras Kondratiuk 
> ---
> v2: updated missed ticketlock.h
> 
>  include/odp/api/align.h  | 4 ++--
>  include/odp/api/atomic.h | 4 ++--
>  include/odp/api/barrier.h| 4 ++--
>  include/odp/api/buffer.h | 4 ++--
>  include/odp/api/byteorder.h  | 4 ++--
>  include/odp/api/classification.h | 4 ++--
>  include/odp/api/compiler.h   | 4 ++--
>  include/odp/api/config.h | 4 ++--
>  include/odp/api/cpumask.h| 4 ++--
>  include/odp/api/crypto.h | 4 ++--
>  include/odp/api/debug.h  | 4 ++--
>  include/odp/api/event.h  | 4 ++--
>  include/odp/api/hints.h  | 4 ++--
>  include/odp/api/init.h   | 4 ++--
>  include/odp/api/packet.h | 4 ++--
>  include/odp/api/packet_flags.h   | 4 ++--
>  include/odp/api/packet_io.h  | 4 ++--
>  include/odp/api/pool.h   | 4 ++--
>  include/odp/api/queue.h  | 4 ++--
>  include/odp/api/random.h | 4 ++--
>  include/odp/api/rwlock.h | 4 ++--
>  include/odp/api/schedule.h   | 4 ++--
>  include/odp/api/shared_memory.h  | 4 ++--
>  include/odp/api/spinlock.h   | 4 ++--
>  include/odp/api/std_types.h  | 4 ++--
>  include/odp/api/sync.h   | 4 ++--
>  include/odp/api/system_info.h| 4 ++--
>  include/odp/api/thread.h | 4 ++--
>  include/odp/api/ticketlock.h | 4 ++--
>  include/odp/api/time.h   | 4 ++--
>  include/odp/api/timer.h  | 4 ++--
>  include/odp/api/version.h| 4 ++--
>  32 files changed, 64 insertions(+), 64 deletions(-)
> 
> diff --git a/include/odp/api/align.h b/include/odp/api/align.h
> index b97ee57..97cedc3 100644
> --- a/include/odp/api/align.h
> +++ b/include/odp/api/align.h
> @@ -11,8 +11,8 @@
>   * ODP alignments
>   */
> 
> -#ifndef ODP_ALIGN_H_
> -#define ODP_ALIGN_H_
> +#ifndef ODP_API_ALIGN_H_
> +#define ODP_API_ALIGN_H_
> 
>  #ifdef __cplusplus
>  extern "C" {
> diff --git a/include/odp/api/atomic.h b/include/odp/api/atomic.h
> index 9e759fb..ba5c354 100644
> --- a/include/odp/api/atomic.h
> +++ b/include/odp/api/atomic.h
> @@ -11,8 +11,8 @@
>   * ODP atomic operations
>   */
> 
> -#ifndef ODP_ATOMIC_H_
> -#define ODP_ATOMIC_H_
> +#ifndef ODP_API_ATOMIC_H_
> +#define ODP_API_ATOMIC_H_
> 
>  #ifdef __cplusplus
>  extern "C" {
> diff --git a/include/odp/api/barrier.h b/include/odp/api/barrier.h
> index 2066210..35f0981 100644
> --- a/include/odp/api/barrier.h
> +++ b/include/odp/api/barrier.h
> @@ -11,8 +11,8 @@
>   * ODP execution barriers
>   */
> 
> -#ifndef ODP_BARRIER_H_
> -#define ODP_BARRIER_H_
> +#ifndef ODP_API_BARRIER_H_
> +#define ODP_API_BARRIER_H_
> 
>  #ifdef __cplusplus
>  extern "C" {
> diff --git a/include/odp/api/buffer.h b/include/odp/api/buffer.h
> index 4bbac1e..9ad08ea 100644
> --- a/include/odp/api/buffer.h
> +++ b/include/odp/api/buffer.h
> @@ -11,8 +11,8 @@
>   * ODP buffer descriptor
>   */
> 
> -#ifndef ODP_BUFFER_H_
> -#define ODP_BUFFER_H_
> +#ifndef ODP_API_BUFFER_H_
> +#define ODP_API_BUFFER_H_
> 
>  #ifdef __cplusplus
>  extern "C" {
> diff --git a/include/odp/api/byteorder.h b/include/odp/api/byteorder.h
> index 3a36afc..a7b3647 100644
> --- a/include/odp/api/byteorder.h
> +++ b/include/odp/api/byteorder.h
> @@ -11,8 +11,8 @@
>   * ODP byteorder
>   */
> 
> -#ifndef ODP_BYTEORDER_H_
> -#define ODP_BYTEORDER_H_
> +#ifndef ODP_API_BYTEORDER_H_
> +#define ODP_API_BYTEORDER_H_
> 
>  #ifdef __cplusplus
>  extern "C" {
> diff --git a/include/odp/api/classification.h
> b/include/odp/api/classification.h
> index 5a61bd8..8758fb5 100644
> --- a/include/odp/api/classification.h
> +++ b/include/odp/api/classification.h
> @@ -11,8 +11,8 @@
>   * ODP classification descriptor
>   */
> 
> -#ifndef ODP_CLASSIFY_H_
> -#define ODP_CLASSIFY_H_
> +#ifndef ODP_API_CLASSIFY_H_
> +#define ODP_API_CLASSIFY_H_
> 
>  #ifdef __cplusplus
>  extern "C" {
> diff --git a/include/odp/api/compiler.h b/include/odp/api/compiler.h
> index 71a4431..5a24bfb 100644
> --- a/include/odp/api/compiler.h
> +++ b/include/odp/api/compiler.h
> @@ -11,8 +11,8 @@
>   * Compiler related
>   */
> 
> -#ifndef OD

Re: [lng-odp] [PATCHv2] api: pool: move buffer allocation to buffer.h

[Savolainen, Petri (NSN - FI/Espoo)]

Reviewed-by: Petri Savolainen 

> -Original Message-
> From: ext Taras Kondratiuk [mailto:taras.kondrat...@linaro.org]
> Sent: Thursday, February 05, 2015 7:37 PM
> To: lng-odp@lists.linaro.org
> Cc: Savolainen, Petri (NSN - FI/Espoo); Taras Kondratiuk
> Subject: [PATCHv2] api: pool: move buffer allocation to buffer.h
> 
> Signed-off-by: Taras Kondratiuk 
> ---
>  include/odp/api/buffer.h  | 19 +++
>  include/odp/api/pool.h| 20 
>  platform/linux-generic/include/odp/pool.h |  1 +
>  3 files changed, 20 insertions(+), 20 deletions(-)
> 
> diff --git a/include/odp/api/buffer.h b/include/odp/api/buffer.h
> index 09bddf2..4bbac1e 100644
> --- a/include/odp/api/buffer.h
> +++ b/include/odp/api/buffer.h
> @@ -105,6 +105,25 @@ int odp_buffer_is_valid(odp_buffer_t buf);
>  odp_pool_t odp_buffer_pool(odp_buffer_t buf);
> 
>  /**
> + * Buffer alloc
> + *
> + * The validity of a buffer can be cheked at any time with
> odp_buffer_is_valid()
> + * @param pool  Pool handle
> + *
> + * @return Handle of allocated buffer
> + * @retval ODP_BUFFER_INVALID  Buffer could not be allocated
> + */
> +odp_buffer_t odp_buffer_alloc(odp_pool_t pool);
> +
> +/**
> + * Buffer free
> + *
> + * @param buf   Buffer handle
> + *
> + */
> +void odp_buffer_free(odp_buffer_t buf);
> +
> +/**
>   * Print buffer metadata to STDOUT
>   *
>   * @param buf  Buffer handle
> diff --git a/include/odp/api/pool.h b/include/odp/api/pool.h
> index 14d18fb..f5dda10 100644
> --- a/include/odp/api/pool.h
> +++ b/include/odp/api/pool.h
> @@ -22,7 +22,6 @@ extern "C" {
> 
>  #include 
>  #include 
> -#include 
>  #include 
> 
>  /** @addtogroup odp_buffer
> @@ -195,25 +194,6 @@ void odp_pool_print(odp_pool_t pool);
>  uint64_t odp_pool_to_u64(odp_pool_t hdl);
> 
>  /**
> - * Buffer alloc
> - *
> - * The validity of a buffer can be cheked at any time with
> odp_buffer_is_valid()
> - * @param pool  Pool handle
> - *
> - * @return Handle of allocated buffer
> - * @retval ODP_BUFFER_INVALID  Buffer could not be allocated
> - */
> -odp_buffer_t odp_buffer_alloc(odp_pool_t pool);
> -
> -/**
> - * Buffer free
> - *
> - * @param buf   Buffer handle
> - *
> - */
> -void odp_buffer_free(odp_buffer_t buf);
> -
> -/**
>   * @}
>   */
> 
> diff --git a/platform/linux-generic/include/odp/pool.h b/platform/linux-
> generic/include/odp/pool.h
> index 0591fcf..e68b11e 100644
> --- a/platform/linux-generic/include/odp/pool.h
> +++ b/platform/linux-generic/include/odp/pool.h
> @@ -25,6 +25,7 @@ extern "C" {
>   * @}
>   */
> 
> +#include 
>  #include 
> 
>  #ifdef __cplusplus
> --
> 1.9.1


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

Re: [lng-odp] [PATCH] api: odp_schedule.h: use int to match return type

[Savolainen, Petri (NSN - FI/Espoo)]

Reviewed-by: Petri Savolainen 

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
> Sent: Thursday, February 05, 2015 6:20 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCH] api: odp_schedule.h: use int to match return
> type
> 
> Use (signed) int for parameter that should match return type of function.
> 
> Signed-off-by: Ola Liljedahl 
> ---
> (This document/code contribution attached is provided under the terms of
> agreement LES-LTM-21309)
> 
>  include/odp/api/schedule.h| 2 +-
>  platform/linux-generic/odp_schedule.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/odp/api/schedule.h b/include/odp/api/schedule.h
> index 3019b84..226dc9b 100644
> --- a/include/odp/api/schedule.h
> +++ b/include/odp/api/schedule.h
> @@ -87,7 +87,7 @@ odp_event_t odp_schedule(odp_queue_t *from, uint64_t
> wait);
>   * @return Number of events outputed (0 ... num)
>   */
>  int odp_schedule_multi(odp_queue_t *from, uint64_t wait, odp_event_t
> events[],
> -unsigned int num);
> +int num);
> 
>  /**
>   * Pause scheduling
> diff --git a/platform/linux-generic/odp_schedule.c b/platform/linux-
> generic/odp_schedule.c
> index 999c800..3427082 100644
> --- a/platform/linux-generic/odp_schedule.c
> +++ b/platform/linux-generic/odp_schedule.c
> @@ -386,7 +386,7 @@ odp_event_t odp_schedule(odp_queue_t *out_queue,
> uint64_t wait)
> 
> 
>  int odp_schedule_multi(odp_queue_t *out_queue, uint64_t wait,
> -odp_event_t events[], unsigned int num)
> +odp_event_t events[], int num)
>  {
>   return schedule_loop(out_queue, wait, events, num, MAX_DEQ);
>  }
> --
> 1.9.1
> 
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp

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

[lng-odp] return type mismatch

[Savolainen, Petri (NSN - FI/Espoo)]

Hi,

This call has still int vs. unsigned int mismatch. 

*
* @return Number of events outputed (0 ... num)
*/
int odp_schedule_multi(odp_queue_t *from, uint64_t wait, odp_event_t events[],
   unsigned int num);


"int num" would be according to our new policy. Negative return values are not 
needed (yet), but better to leave that door open.

-Petri


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

Re: [lng-odp] [PATCH] api: pool: move buffer allocation to buffer.h

[Savolainen, Petri (NSN - FI/Espoo)]

This move is OK. Just remove also this:

#include 

since there's not dependency anymore.

-petri


> -Original Message-
> From: ext Taras Kondratiuk [mailto:taras.kondrat...@linaro.org]
> Sent: Thursday, February 05, 2015 4:19 PM
> To: lng-odp@lists.linaro.org
> Cc: Savolainen, Petri (NSN - FI/Espoo); Taras Kondratiuk
> Subject: [PATCH] api: pool: move buffer allocation to buffer.h
> 
> Signed-off-by: Taras Kondratiuk 
> ---
>  include/odp/api/buffer.h | 19 +++
>  include/odp/api/pool.h   | 19 ---
>  2 files changed, 19 insertions(+), 19 deletions(-)
> 
> diff --git a/include/odp/api/buffer.h b/include/odp/api/buffer.h
> index 09bddf2..4bbac1e 100644
> --- a/include/odp/api/buffer.h
> +++ b/include/odp/api/buffer.h
> @@ -105,6 +105,25 @@ int odp_buffer_is_valid(odp_buffer_t buf);
>  odp_pool_t odp_buffer_pool(odp_buffer_t buf);
> 
>  /**
> + * Buffer alloc
> + *
> + * The validity of a buffer can be cheked at any time with
> odp_buffer_is_valid()
> + * @param pool  Pool handle
> + *
> + * @return Handle of allocated buffer
> + * @retval ODP_BUFFER_INVALID  Buffer could not be allocated
> + */
> +odp_buffer_t odp_buffer_alloc(odp_pool_t pool);
> +
> +/**
> + * Buffer free
> + *
> + * @param buf   Buffer handle
> + *
> + */
> +void odp_buffer_free(odp_buffer_t buf);
> +
> +/**
>   * Print buffer metadata to STDOUT
>   *
>   * @param buf  Buffer handle
> diff --git a/include/odp/api/pool.h b/include/odp/api/pool.h
> index 14d18fb..b0b26e4 100644
> --- a/include/odp/api/pool.h
> +++ b/include/odp/api/pool.h
> @@ -195,25 +195,6 @@ void odp_pool_print(odp_pool_t pool);
>  uint64_t odp_pool_to_u64(odp_pool_t hdl);
> 
>  /**
> - * Buffer alloc
> - *
> - * The validity of a buffer can be cheked at any time with
> odp_buffer_is_valid()
> - * @param pool  Pool handle
> - *
> - * @return Handle of allocated buffer
> - * @retval ODP_BUFFER_INVALID  Buffer could not be allocated
> - */
> -odp_buffer_t odp_buffer_alloc(odp_pool_t pool);
> -
> -/**
> - * Buffer free
> - *
> - * @param buf   Buffer handle
> - *
> - */
> -void odp_buffer_free(odp_buffer_t buf);
> -
> -/**
>   * @}
>   */
> 
> --
> 1.9.1


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

Re: [lng-odp] [PATCHv7] api: odp_shared_memory.h: updated return descriptions

[Savolainen, Petri (NSN - FI/Espoo)]

Reviewed-by: Petri Savolainen 

-Petri

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
> Sent: Thursday, February 05, 2015 3:41 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv7] api: odp_shared_memory.h: updated return
> descriptions
> 
> Also corrected return description of odp_shm_reserve(), it returns
> ODP_SHM_INVALID (not NULL) on failure.
> 
> Signed-off-by: Ola Liljedahl 
> ---
> (This document/code contribution attached is provided under the terms of
> agreement LES-LTM-21309)
> 
>  include/odp/api/shared_memory.h | 18 +++---
>  1 file changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/include/odp/api/shared_memory.h
> b/include/odp/api/shared_memory.h
> index d4445f7..8d8df3f 100644
> --- a/include/odp/api/shared_memory.h
> +++ b/include/odp/api/shared_memory.h
> @@ -71,7 +71,8 @@ typedef struct odp_shm_info_t {
>   * @param[in] flags  Shared memory parameter flags (ODP_SHM_*).
>   *   Default value is 0.
>   *
> - * @return Pointer to the reserved block, or NULL
> + * @return Handle of the reserved block
> + * @retval ODP_SHM_INVALID on failure
>   */
>  odp_shm_t odp_shm_reserve(const char *name, uint64_t size, uint64_t
> align,
> uint32_t flags);
> @@ -84,9 +85,8 @@ odp_shm_t odp_shm_reserve(const char *name, uint64_t
> size, uint64_t align,
>   *
>   * @param[in] shm Block handle
>   *
> - * @retval 0 if the handle is already free
> - * @retval 0 if the handle free succeeds
> - * @retval -1 on failure to free the handle
> + * @retval 0 on success
> + * @retval <0 on failure
>   */
>  int odp_shm_free(odp_shm_t shm);
> 
> @@ -96,7 +96,7 @@ int odp_shm_free(odp_shm_t shm);
>   * @param[in] name   Name of the block
>   *
>   * @return A handle to the block if it is found by name
> - * @retval #ODP_SHM_INVALID if the block is not found
> + * @retval ODP_SHM_INVALID on failure
>   */
>  odp_shm_t odp_shm_lookup(const char *name);
> 
> @@ -106,18 +106,22 @@ odp_shm_t odp_shm_lookup(const char *name);
>   *
>   * @param[in] shm   Block handle
>   *
> - * @return Memory block address, or NULL on error
> + * @return Memory block address
> + * @retval NULL on failure
>   */
>  void *odp_shm_addr(odp_shm_t shm);
> 
> 
>  /**
>   * Shared memory block info
> + * @note This is the only shared memory API function which accepts
> invalid
> + * shm handles (any bit value) without causing undefined behavior.
>   *
>   * @param[in]  shm   Block handle
>   * @param[out] info  Block info pointer for output
>   *
> - * @return 0 on success, otherwise non-zero
> + * @retval 0 on success
> + * @retval <0 on failure
>   */
>  int odp_shm_info(odp_shm_t shm, odp_shm_info_t *info);
> 
> --
> 1.9.1
> 
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp

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

Re: [lng-odp] [PATCHv6 0/9] Cleanup of parameters and return values

[Savolainen, Petri (NSN - FI/Espoo)]

In summary, patch set is OK to merge after these updates:
- patch 3/9: "api: odp_buffer.h: undefined behavior description"
  * leave out the patch all together
- patch 6/9: "api: odp_shared_memory.h: updated return descriptions"
  * do bug correction: retval ODP_SHM_INVALID instead of NULL

Reviewed-by: Petri Savolainen 

-Petri


> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
> Sent: Wednesday, February 04, 2015 11:07 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv6 0/9] Cleanup of parameters and return values
> 
> Changes since version 5:
> Per feedback from Petri S.
> Renamed ODP_CPUMASK_BUFSIZE to ODP_CPUMASK_STR_SIZE.
> Renamed ODP_PKTIO_MACADDRSIZE to ODP_PKTIO_MACADDR_MAXSIZE.
> Reverted parameter name change from "id" to "hdl" in patch #2.
> Reverted description of odp_pktio_mac_addr() in patch #2.
> Split out patches #8-#9.
> A number of patches that passed review already merged.
> 
> Changes since version 4:
> Restored parameter names of odp_cpumask_to_str(), odp_pktio_mac_addr()
> and odp_hw_random_get().
> 
> Changes since version 3:
> Removed unnecessary braces from odp_cpumask.c in patch #1.
> 
> Changes since version 2:
> Rebased, e.g. due to API restructuring.
> Split two patches, separating documentation updates from API changes.
> Reordered patches, all serious API changes are now contained in patches 1-
> 4.
> 
> Patches #1-#2:
> odp_cpumask_to_str() and odp_pktio_mac_addr() takes output buffer
> size as input and returns number of chars/bytes written (on success),
> a negative value on failure.
> Added defines (ODP_CPUMASK_STR_SIZE, ODP_PKTIO_MACADDR_MAXSIZE) for
> recommended output buffer sizes.
> Updated the implementations of these calls.
> Updated all usages of these calls in example and test programs.
> 
> Patches #3-#7:
> Updated doxygen descriptions, particularly the @return/@retval
> descriptions.
> Specifically documented those API calls which are guaranteed to handle
> invalid/stale handles.
> No change of implementation necessary.
> 
> Patch #8:
> odp_pktio_recv() and odp_pktio_send() use int for 'len' parameter to
> match return type.
> 
> Patch #9:
> Use 'pktio' as the parameter name for all packet IO handles.
> Unify the descriptions to say "packet IO handle".
> 
> (This document/code contribution attached is provided under the terms of
> agreement LES-LTM-21309)
> 
> Ola Liljedahl (9):
>   api: odp_cpumask.h: odp_cpumask_to_str() return chars written or error
>   api: odp_pktio.h: odp_pktio_mac_addr() return chars written or error
>   api: odp_buffer.h: undefined behavior description
>   api: odp_init.h: updated return descriptions
>   api: odp_packet_io.h: updated return descriptions
>   api: odp_shared_memory.h: updated return descriptions
>   api: odp_timer.h: updated return descriptions
>   api: odp_packet_io.h: use int for size of pkt_tables
>   api: odp_packet_io.h: clean up pktio parameter names and descriptions
> 
>  example/generator/odp_generator.c  |   4 +-
>  example/ipsec/odp_ipsec.c  |   4 +-
>  example/l2fwd/odp_l2fwd.c  |   4 +-
>  example/packet/odp_pktio.c |   4 +-
>  example/timer/odp_timer_test.c |   4 +-
>  include/odp/api/buffer.h   |   4 +-
>  include/odp/api/cpumask.h  |  23 +++-
>  include/odp/api/init.h |  22 ++--
>  include/odp/api/packet_io.h| 135 
> -
>  include/odp/api/shared_memory.h|  18 +--
>  include/odp/api/timer.h|  38 ++
>  .../linux-generic/include/odp/plat/cpumask_types.h |   5 +
>  .../include/odp/plat/packet_io_types.h |   2 +
>  platform/linux-generic/odp_cpumask.c   |  26 ++--
>  platform/linux-generic/odp_packet_io.c |  15 +--
>  test/api_test/odp_common.c |   4 +-
>  test/performance/odp_scheduling.c  |   4 +-
>  test/validation/odp_pktio.c|   8 +-
>  18 files changed, 176 insertions(+), 148 deletions(-)
> 
> --
> 1.9.1
> 
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp

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

Re: [lng-odp] [PATCHv6 5/9] api: odp_packet_io.h: updated return descriptions

[Savolainen, Petri (NSN - FI/Espoo)]

> >>   */
> >>  int odp_pktio_send(odp_pktio_t id, odp_packet_t pkt_table[], unsigned
> >> len);
> >
> >
> > Same here: int/int vs. int/unsigned
> Those changes are in another patch (the last one I think).

Found it. That's OK for me.

-Petri

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

Re: [lng-odp] [PATCHv6 6/9] api: odp_shared_memory.h: updated return descriptions

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
> Sent: Wednesday, February 04, 2015 11:07 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv6 6/9] api: odp_shared_memory.h: updated return
> descriptions
> 
> Signed-off-by: Ola Liljedahl 
> ---
> (This document/code contribution attached is provided under the terms of
> agreement LES-LTM-21309)
> 
>  include/odp/api/shared_memory.h | 18 +++---
>  1 file changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/include/odp/api/shared_memory.h
> b/include/odp/api/shared_memory.h
> index d4445f7..78e11a5 100644
> --- a/include/odp/api/shared_memory.h
> +++ b/include/odp/api/shared_memory.h
> @@ -71,7 +71,8 @@ typedef struct odp_shm_info_t {
>   * @param[in] flags  Shared memory parameter flags (ODP_SHM_*).
>   *   Default value is 0.
>   *
> - * @return Pointer to the reserved block, or NULL
> + * @return Handle of the reserved block
> + * @retval NULL on failure
>   */



There's actually bug in the original text. It should be:

@retval ODP_SHM_INVALID on failure

Maybe it's worth correcting it in this series, instead of correcting it on top 
of it.


-Petri



>  odp_shm_t odp_shm_reserve(const char *name, uint64_t size, uint64_t
> align,
> uint32_t flags);
> @@ -84,9 +85,8 @@ odp_shm_t odp_shm_reserve(const char *name, uint64_t
> size, uint64_t align,
>   *
>   * @param[in] shm Block handle
>   *
> - * @retval 0 if the handle is already free
> - * @retval 0 if the handle free succeeds
> - * @retval -1 on failure to free the handle
> + * @retval 0 on success
> + * @retval <0 on failure to free the handle
>   */
>  int odp_shm_free(odp_shm_t shm);
> 
> @@ -96,7 +96,7 @@ int odp_shm_free(odp_shm_t shm);
>   * @param[in] name   Name of the block
>   *
>   * @return A handle to the block if it is found by name
> - * @retval #ODP_SHM_INVALID if the block is not found
> + * @retval ODP_SHM_INVALID on failure
>   */
>  odp_shm_t odp_shm_lookup(const char *name);
> 
> @@ -106,18 +106,22 @@ odp_shm_t odp_shm_lookup(const char *name);
>   *
>   * @param[in] shm   Block handle
>   *
> - * @return Memory block address, or NULL on error
> + * @return Memory block address
> + * @retval NULL on failure
>   */
>  void *odp_shm_addr(odp_shm_t shm);
> 
> 
>  /**
>   * Shared memory block info
> + * @note This is the only shared memory API function which accepts
> invalid
> + * shm handles (any bit value) without causing undefined behavior.
>   *
>   * @param[in]  shm   Block handle
>   * @param[out] info  Block info pointer for output
>   *
> - * @return 0 on success, otherwise non-zero
> + * @retval 0 on success
> + * @retval <0 on failure
>   */
>  int odp_shm_info(odp_shm_t shm, odp_shm_info_t *info);
> 
> --
> 1.9.1
> 
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp

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

Re: [lng-odp] [PATCHv6 5/9] api: odp_packet_io.h: updated return descriptions

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
> Sent: Wednesday, February 04, 2015 11:07 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv6 5/9] api: odp_packet_io.h: updated return
> descriptions
> 
> Signed-off-by: Ola Liljedahl 
> ---
> (This document/code contribution attached is provided under the terms of
> agreement LES-LTM-21309)
> 
>  include/odp/api/packet_io.h | 55 
> -
>  1 file changed, 34 insertions(+), 21 deletions(-)
> 
> diff --git a/include/odp/api/packet_io.h b/include/odp/api/packet_io.h
> index 9d18489..36be5b1 100644
> --- a/include/odp/api/packet_io.h
> +++ b/include/odp/api/packet_io.h
> @@ -57,7 +57,8 @@ extern "C" {
>   * @param pool   Pool from which to allocate buffers for storing packets
>   *   received over this packet IO
>   *
> - * @return ODP packet IO handle or ODP_PKTIO_INVALID on error
> + * @return ODP packet IO handle
> + * @retval ODP_PKTIO_INVALID on failure
>   *
>   * @note dev name loop is specially pktio reserved name for
>   *device used for testing. Usually it's loop back
> @@ -70,7 +71,8 @@ odp_pktio_t odp_pktio_open(const char *dev, odp_pool_t
> pool);
>   *
>   * @param id  ODP packet IO handle
>   *
> - * @return 0 on success or -1 on error
> + * @retval 0 on success
> + * @retval <0 on failure
>   */
>  int odp_pktio_close(odp_pktio_t id);
> 
> @@ -79,7 +81,8 @@ int odp_pktio_close(odp_pktio_t id);
>   *
>   * @param dev Packet IO device name
>   *
> - * @return ODP packet IO handle or ODP_PKTIO_INVALID
> + * @return ODP packet IO handle
> + * @retval ODP_PKTIO_INVALID on failure
>   */
>  odp_pktio_t odp_pktio_lookup(const char *dev);
> 
> @@ -90,7 +93,8 @@ odp_pktio_t odp_pktio_lookup(const char *dev);
>   * @param pkt_table[] Storage for received packets (filled by function)
>   * @param len Length of pkt_table[], i.e. max number of pkts to
> receive
>   *
> - * @return Number of packets received or -1 on error
> + * @return Number of packets received
> + * @retval <0 on failure
>   */
>  int odp_pktio_recv(odp_pktio_t id, odp_packet_t pkt_table[], unsigned
> len);



I think you missed this comment from yesterday:
 
About "unsigned len": if I remember correctly we agreed that functions that 
handle number of objects (not bytes or offset or chars) would have int both on 
input and output.


 int odp_pktio_recv(odp_pktio_t hdl, odp_packet_t pkt_table[], int len);


 int num = 10;
 int ret;

 ret = odp_pktio_recv(pktio, pkts[], num);

 if (ret < num)
...


I short: use int for both return and len. 



> 
> @@ -101,16 +105,18 @@ int odp_pktio_recv(odp_pktio_t id, odp_packet_t
> pkt_table[], unsigned len);
>   * @param pkt_table[]  Array of packets to send
>   * @param len  length of pkt_table[]
>   *
> - * @return Number of packets sent or -1 on error
> + * @return Number of packets sent
> + * @retval <0 on failure
>   */
>  int odp_pktio_send(odp_pktio_t id, odp_packet_t pkt_table[], unsigned
> len);


Same here: int/int vs. int/unsigned 


-Petri


> 
>  /**
>   * Set the default input queue to be associated with a pktio handle
>   *
> - * @param id ODP packet IO handle
> + * @param id ODP packet IO handle
>   * @param queue default input queue set
> - * @return  0 on success or -1 on error
> + * @retval  0 on success
> + * @retval <0 on failure
>   */
>  int odp_pktio_inq_setdef(odp_pktio_t id, odp_queue_t queue);
> 
> @@ -119,7 +125,8 @@ int odp_pktio_inq_setdef(odp_pktio_t id, odp_queue_t
> queue);
>   *
>   * @param id  ODP packet IO handle
>   *
> - * @return Default input queue set or ODP_QUEUE_INVALID on error
> + * @return Default input queue set
> + * @retval ODP_QUEUE_INVALID on failure
>   */
>  odp_queue_t odp_pktio_inq_getdef(odp_pktio_t id);
> 
> @@ -128,7 +135,8 @@ odp_queue_t odp_pktio_inq_getdef(odp_pktio_t id);
>   *
>   * @param id  ODP packet IO handle
>   *
> - * @return 0 on success or -1 on error
> + * @retval 0 on success
> + * @retval <0 on failure
>   */
>  int odp_pktio_inq_remdef(odp_pktio_t id);
> 
> @@ -137,7 +145,8 @@ int odp_pktio_inq_remdef(odp_pktio_t id);
>   *
>   * @param id ODP packet IO handle
>   *
> - * @return Default out queue or ODP_QUEUE_INVALID on error
> + * @return Default out queue
> + * @retval ODP_QUEUE_INVALID on failure
>   */
>  odp_queue_t odp_pktio_outq_getdef(odp_pktio_t id);
> 
> @@ -146,8 +155,8 @@ odp_queue_t odp_pktio_outq_getdef(odp_pktio_t id);
>   *
>   * @param[in] id  ODP packet IO handle.
>   *
> - * @retval MTU value >0 on success.
> - * @retval -1 on any error or not existance pktio id.
> + * @return MTU value on success
> + * @retval <0 on failure
>   */
>  int odp_pktio_mtu(odp_pktio_t id);
> 
> @@ -157,8 +166,8 @@ int odp_pktio_mtu(odp_pktio_t id);
>   * @param[in] id ODP packet IO handle.
>   * @param[in] enable 1 to enable, 0 to disable.
>   *
> - * @retval 0 on success.
> - * 

Re: [lng-odp] [PATCHv6 3/9] api: odp_buffer.h: undefined behavior description

[Savolainen, Petri (NSN - FI/Espoo)]

As discussed before, I think this function can crash on bad handles as any 
other buffer API call. So, let's leave out this patch.

More documentation on "sanity" checking can be added with another patch.

-Petri

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
> Sent: Wednesday, February 04, 2015 11:07 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv6 3/9] api: odp_buffer.h: undefined behavior
> description
> 
> Signed-off-by: Ola Liljedahl 
> ---
> (This document/code contribution attached is provided under the terms of
> agreement LES-LTM-21309)
> 
>  include/odp/api/buffer.h | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/include/odp/api/buffer.h b/include/odp/api/buffer.h
> index 09bddf2..e0e25b0 100644
> --- a/include/odp/api/buffer.h
> +++ b/include/odp/api/buffer.h
> @@ -88,7 +88,9 @@ uint32_t odp_buffer_size(odp_buffer_t buf);
>  /**
>   * Tests if buffer is valid
>   *
> - * @param buf  Buffer handle
> + * @param buf  Buffer handle (possibly invalid)
> + * @note This is the only buffer API function which accepts invalid
> buffer
> + * handles (any bit value) without causing undefined behavior.
>   *
>   * @retval 1 Buffer handle represents a valid buffer.
>   * @retval 0 Buffer handle does not represent a valid buffer.
> --
> 1.9.1
> 
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp

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

Re: [lng-odp] [PATCHv5 00/18] Cleanup return semantics and descriptions

[Savolainen, Petri (NSN - FI/Espoo)]

Hi,

I sent out review comments for patches: 1, 2, 5, 8, 11, 14, 16.


Other than those can be merged already (if possible without conflicts). 
Hopefully those can be merged ASAP so that other patches (on the list) can be 
rebased on that.

For patches: 3, 4, 6, 7, 9, 10, 12, 13, 15, 17, 18.

Reviewed-by: Petri Savolainen 


-Petri


> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
> Sent: Tuesday, February 03, 2015 6:48 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv5 00/18] Cleanup return semantics and
> descriptions
> 
> Changes since version 4:
> Restored parameter names of odp_cpumask_to_str(), odp_pktio_mac_addr()
> and +odp_hw_random_get().
> 
> Changes since version 3:
> Removed unnecessary braces from odp_cpumask.c in patch #1.
> 
> Changes since version 2:
> Rebased, e.g. due to API restructuring.
> Split two patches, separating documentation updates from API changes.
> Reordered patches, all serious API changes are now contained in patches 1-
> 4.
> 
> Patches #1-#3:
> odp_cpumask_to_str(), odp_pktio_mac_addr() and odp_hw_random_get() takes
> output buffer size as input and returns number of chars/bytes written (on
> success), a negative value on failure.
> Added defines (ODP_CPUMASK_BUFSIZE, ODP_PKTIO_MACADDRSIZE) for recommended
> output buffer sizes.
> Updated the implementations of these calls.
> Updated all usages of these calls in example and test programs.
> 
> Patch #4:
> Changed the definition of odp_queue_enq_multi() to support partial success
> (e.g. enqueued some but not all of the events specified). Returns the
> number
> of events enqueued (equivalent to odp_queue_deq_multi()). This change is
> necessary to support ODP implementations that use fixed size queues (e.g.
> ODP linux-dpdk).
> Updated the implementation in odp_queue.c to conform to the new semantics.
> Updated the necessary test/validation/performance programs.
> 
> Patches #5-#18:
> Updated doxygen descriptions, particularly the @return/@retval
> descriptions.
> Specifically documented those API calls which are guaranteed to handle
> invalid/stale handles.
> No change of implementation necessary.
> 
> (This document/code contribution attached is provided under the terms of
> agreement LES-LTM-21309)
> 
> Ola Liljedahl (18):
>   api: odp_cpumask.h: odp_cpumask_to_str() return chars written or error
>   api: odp_pktio.h: odp_pktio_mac_addr() return chars written or error
>   api: odp_crypto.h: odp_hw_random_get(): return number of bytes written
>   api: odp_queue.h: odp_queue_enq_multi() returns partial success
>   api: odp_buffer.h: undefined behavior description
>   api: odp_byteorder.h: updated comment
>   api: odp_classification.h: updated return descriptions
>   api: odp_init.h: updated return descriptions
>   api: odp_packet.h: updated return descriptions
>   api: odp_packet_flags.h: updated return descriptions
>   api: odp_packet_io.h: updated return descriptions
>   api: odp_queue.h: updated return descriptions
>   api: odp_schedule.h: updated return descriptions
>   api: odp_shared_memory.h: updated return descriptions
>   api: odp_thread.h: updated return descriptions
>   api: odp_timer.h: updated return descriptions
>   api: odp_cpumask.h: updated descriptions, added const
>   api: odp_crypto.h: updated return descriptions
> 
>  example/generator/odp_generator.c  |   4 +-
>  example/ipsec/odp_ipsec.c  |   4 +-
>  example/ipsec/odp_ipsec_cache.c|   6 +-
>  example/l2fwd/odp_l2fwd.c  |   4 +-
>  example/packet/odp_pktio.c |   4 +-
>  example/timer/odp_timer_test.c |   4 +-
>  include/odp/api/buffer.h   |   4 +-
>  include/odp/api/byteorder.h|   2 +-
>  include/odp/api/classification.h   |  48 
>  include/odp/api/cpumask.h  | 123 +---
> -
>  include/odp/api/crypto.h   |  23 ++--
>  include/odp/api/init.h |  20 ++--
>  include/odp/api/packet.h   |  68 ++--
>  include/odp/api/packet_flags.h |  51 ++---
>  include/odp/api/packet_io.h| 109 ++--
> --
>  include/odp/api/queue.h|  38 ---
>  include/odp/api/schedule.h |   3 +-
>  include/odp/api/shared_memory.h|  17 +--
>  include/odp/api/thread.h   |   6 +-
>  include/odp/api/timer.h|  52 +++--
>  .../linux-generic/include/odp/plat/cpumask_types.h |   5 +
>  .../include/odp/plat/packet_io_types.h |   2 +
>  platform/linux-generic/odp_cpumask.c   |  38 ---
>  platform/linux-generic/odp_crypto.c|   8 +-
>  platfor

Re: [lng-odp] [PATCHv5 14/18] api: odp_shared_memory.h: updated return descriptions

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: ext Ola Liljedahl [mailto:ola.liljed...@linaro.org]
> Sent: Wednesday, February 04, 2015 4:08 PM
> To: Savolainen, Petri (NSN - FI/Espoo)
> Cc: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [PATCHv5 14/18] api: odp_shared_memory.h: updated
> return descriptions
> 
> On 4 February 2015 at 14:50, Savolainen, Petri (NSN - FI/Espoo)
>  wrote:
> >
> >
> >> -Original Message-
> >> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> >> boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
> >> Sent: Tuesday, February 03, 2015 6:48 PM
> >> To: lng-odp@lists.linaro.org
> >> Subject: [lng-odp] [PATCHv5 14/18] api: odp_shared_memory.h: updated
> >> return descriptions
> >>
> >> Updated doxygen descriptions, particularly the @return/@retval
> >> descriptions.
> >> No change of implementation necessary.
> >> Documented API calls which are guaranteed to handle invalid/stale
> handles.
> >>
> >> Signed-off-by: Ola Liljedahl 
> >> ---
> >> (This document/code contribution attached is provided under the terms
> of
> >> agreement LES-LTM-21309)
> >>
> >>  include/odp/api/shared_memory.h | 17 ++---
> >>  1 file changed, 10 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/include/odp/api/shared_memory.h
> >> b/include/odp/api/shared_memory.h
> >> index 5b27b6b..18764ce 100644
> >> --- a/include/odp/api/shared_memory.h
> >> +++ b/include/odp/api/shared_memory.h
> >> @@ -71,7 +71,8 @@ typedef struct odp_shm_info_t {
> >>   * @param[in] flags  Shared memory parameter flags (ODP_SHM_*).
> >>   *   Default value is 0.
> >>   *
> >> - * @return Pointer to the reserved block, or NULL
> >> + * @return Handle of the reserved block
> >> + * @retval NULL on failure
> >>   */
> >>  odp_shm_t odp_shm_reserve(const char *name, uint64_t size, uint64_t
> >> align,
> >> uint32_t flags);
> >> @@ -84,9 +85,8 @@ odp_shm_t odp_shm_reserve(const char *name, uint64_t
> >> size, uint64_t align,
> >>   *
> >>   * @param[in] shm Block handle
> >>   *
> >> - * @retval 0 if the handle is already free
> >> - * @retval 0 if the handle free succeeds
> >> - * @retval -1 on failure to free the handle
> >> + * @retval 0 on success
> >> + * @retval <0 on failure to free the handle
> >>   */
> >>  int odp_shm_free(odp_shm_t shm);
> >>
> >> @@ -96,7 +96,7 @@ int odp_shm_free(odp_shm_t shm);
> >>   * @param[in] name   Name of the block
> >>   *
> >>   * @return A handle to the block if it is found by name
> >> - * @retval #ODP_SHM_INVALID if the block is not found
> >> + * @retval ODP_SHM_INVALID on failure
> >>   */
> >>  odp_shm_t odp_shm_lookup(const char *name);
> >>
> >> @@ -106,18 +106,21 @@ odp_shm_t odp_shm_lookup(const char *name);
> >>   *
> >>   * @param[in] shm   Block handle
> >>   *
> >> - * @return Memory block address, or NULL on error
> >> + * @return Memory block address
> >
> >
> >
> > Missing the failure case.
> No this was intentional.
> How can odp_shm_addr() fail? What are those errors? Can the function
> spuriously return NULL?
> 
> Either the shm handle is valid and the function returns an address.
> Or the handle is invalid and the behavior is undefined (possibly
> function does not return at all).
> 
> If we require odp_shm_addr() to detect invalid shm handles, this
> behavior and requirement needs to be specified. How can an ODP
> implementer otherwise know what needs to be implemented? How can the
> test program writer know what scenarios to test and their expected
> outcomes?

Shm is a shared resource. The address is not necessary coded into the handle.

Due to a synchronization error between threads another thread may have freed 
the shm. If implementation can catch that (shm status changed to "free"), it 
can return NULL. If it cannot catch, it may e.g. crash (undefined behavior).

I think we agreed that, functions which access a shared resource may return 
error vs. functions which access non-shared resources (buffer, packet, tmo, 
event) only cannot return error on a bad handle (but abort or crash). 

Thread A:   Thread B:

// success
if (odp_shm_xxx(shm, ...))
ERROR();

// success
if (odp_shm_xxx(shm, ...))
ERROR();

Re: [lng-odp] [PATCHv5 16/18] api: odp_timer.h: updated return descriptions

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
> Sent: Tuesday, February 03, 2015 6:48 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv5 16/18] api: odp_timer.h: updated return
> descriptions
> 
> Updated doxygen descriptions, particularly the @return/@retval
> descriptions.
> Documented API calls which are guaranteed to handle invalid/stale handles.
> Removed unnecessary warnings of undefined behavior.
> No change of implementation necessary.
> 
> Signed-off-by: Ola Liljedahl 
> ---
> (This document/code contribution attached is provided under the terms of
> agreement LES-LTM-21309)
> 
>  include/odp/api/timer.h | 52 
> -
>  1 file changed, 17 insertions(+), 35 deletions(-)
> 
> diff --git a/include/odp/api/timer.h b/include/odp/api/timer.h
> index 64ccc4b..1b813da 100644
> --- a/include/odp/api/timer.h
> +++ b/include/odp/api/timer.h
> @@ -112,8 +112,8 @@ typedef struct {
>   * @param name   Name of the timer pool. The string will be copied.
>   * @param params Timer pool parameters. The content will be copied.
>   *
> - * @return Timer pool handle if successful, otherwise
> ODP_TIMER_POOL_INVALID
> - * and errno set
> + * @return Timer pool handle on success
> + * @retval ODP_TIMER_POOL_INVALID on failure and errno set
>   */
>  odp_timer_pool_t
>  odp_timer_pool_create(const char *name,
> @@ -135,14 +135,14 @@ void odp_timer_pool_start(void);
>   * Destroy a timer pool, freeing all resources.
>   * All timers must have been freed.
>   *
> - * @param tpid  Timer pool identifier
> + * @param tpid  Timer pool handle
>   */
>  void odp_timer_pool_destroy(odp_timer_pool_t tpid);
> 
>  /**
>   * Convert timer ticks to nanoseconds
>   *
> - * @param tpid  Timer pool identifier
> + * @param tpid  Timer pool handle
>   * @param ticks Timer ticks
>   *
>   * @return Nanoseconds
> @@ -152,7 +152,7 @@ uint64_t odp_timer_tick_to_ns(odp_timer_pool_t tpid,
> uint64_t ticks);
>  /**
>   * Convert nanoseconds to timer ticks
>   *
> - * @param tpid  Timer pool identifier
> + * @param tpid  Timer pool handle
>   * @param nsNanoseconds
>   *
>   * @return Timer ticks
> @@ -162,7 +162,7 @@ uint64_t odp_timer_ns_to_tick(odp_timer_pool_t tpid,
> uint64_t ns);
>  /**
>   * Current tick value
>   *
> - * @param tpid Timer pool identifier
> + * @param tpid Timer pool handle
>   *
>   * @return Current time in timer ticks
>   */
> @@ -181,12 +181,14 @@ typedef struct {
> 
>  /**
>   * Query timer pool configuration and current state
> + * @note This is the only timer API function which accepts invalid
> handles
> + * (any bit value) without causing undefined behavior.


Why? How this is different?

I think all calls accessing the timer pool (a shared resource) have the same 
behavior. Those can crash on bad tpid handles, and may catch stale handles with 
return code or crash.


- Petri



>   *
> - * @param tpid Timer pool identifier
> + * @param tpid Timer pool handle
>   * @param[out] info Pointer to information buffer
>   *
> - * @retval 0 Success
> - * @retval -1 Failure. Info could not be retrieved.
> + * @retval 0 on success
> + * @retval <0 on failure. Info could not be retrieved.
>   */
>  int odp_timer_pool_info(odp_timer_pool_t tpid,
>   odp_timer_pool_info_t *info);
> @@ -198,12 +200,12 @@ int odp_timer_pool_info(odp_timer_pool_t tpid,
>   * the timer pool. The user_ptr is copied to timeouts and can be
> retrieved
>   * using the odp_timeout_user_ptr() call.
>   *
> - * @param tpid Timer pool identifier
> + * @param tpid Timer pool handle
>   * @param queueDestination queue for timeout notifications
>   * @param user_ptr User defined pointer or NULL to be copied to timeouts
>   *
> - * @return Timer handle if successful, otherwise ODP_TIMER_INVALID and
> - *  errno set.
> + * @return Timer handle on success
> + * @retval ODP_TIMER_INVALID on failure and errno set.
>   */
>  odp_timer_t odp_timer_alloc(odp_timer_pool_t tpid,
>   odp_queue_t queue,
> @@ -218,7 +220,8 @@ odp_timer_t odp_timer_alloc(odp_timer_pool_t tpid,
>   * responsibility of the application to handle this timeout when it is
> received.
>   *
>   * @param tim  Timer handle
> - * @return Event handle of timeout event or ODP_EVENT_INVALID
> + * @return Event handle of timeout event
> + * @retval ODP_EVENT_INVALID on failure
>   */
>  odp_event_t odp_timer_free(odp_timer_t tim);
> 
> @@ -228,9 +231,6 @@ odp_event_t odp_timer_free(odp_timer_t tim);
>   * Set (arm) the timer to expire at specific time. The timeout
>   * event will be enqueued when the timer expires.
>   *
> - * Note: any invalid parameters will be treated as programming errors and
> will
> - * cause the application to abort.
> - *
>   * @param tim  Timer
>   * @param abs_tck  Expiration time in absolute timer ticks
>   * @param[in,out] tmo_ev  Referenc

Re: [lng-odp] [PATCHv5 14/18] api: odp_shared_memory.h: updated return descriptions

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
> Sent: Tuesday, February 03, 2015 6:48 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv5 14/18] api: odp_shared_memory.h: updated
> return descriptions
> 
> Updated doxygen descriptions, particularly the @return/@retval
> descriptions.
> No change of implementation necessary.
> Documented API calls which are guaranteed to handle invalid/stale handles.
> 
> Signed-off-by: Ola Liljedahl 
> ---
> (This document/code contribution attached is provided under the terms of
> agreement LES-LTM-21309)
> 
>  include/odp/api/shared_memory.h | 17 ++---
>  1 file changed, 10 insertions(+), 7 deletions(-)
> 
> diff --git a/include/odp/api/shared_memory.h
> b/include/odp/api/shared_memory.h
> index 5b27b6b..18764ce 100644
> --- a/include/odp/api/shared_memory.h
> +++ b/include/odp/api/shared_memory.h
> @@ -71,7 +71,8 @@ typedef struct odp_shm_info_t {
>   * @param[in] flags  Shared memory parameter flags (ODP_SHM_*).
>   *   Default value is 0.
>   *
> - * @return Pointer to the reserved block, or NULL
> + * @return Handle of the reserved block
> + * @retval NULL on failure
>   */
>  odp_shm_t odp_shm_reserve(const char *name, uint64_t size, uint64_t
> align,
> uint32_t flags);
> @@ -84,9 +85,8 @@ odp_shm_t odp_shm_reserve(const char *name, uint64_t
> size, uint64_t align,
>   *
>   * @param[in] shm Block handle
>   *
> - * @retval 0 if the handle is already free
> - * @retval 0 if the handle free succeeds
> - * @retval -1 on failure to free the handle
> + * @retval 0 on success
> + * @retval <0 on failure to free the handle
>   */
>  int odp_shm_free(odp_shm_t shm);
> 
> @@ -96,7 +96,7 @@ int odp_shm_free(odp_shm_t shm);
>   * @param[in] name   Name of the block
>   *
>   * @return A handle to the block if it is found by name
> - * @retval #ODP_SHM_INVALID if the block is not found
> + * @retval ODP_SHM_INVALID on failure
>   */
>  odp_shm_t odp_shm_lookup(const char *name);
> 
> @@ -106,18 +106,21 @@ odp_shm_t odp_shm_lookup(const char *name);
>   *
>   * @param[in] shm   Block handle
>   *
> - * @return Memory block address, or NULL on error
> + * @return Memory block address



Missing the failure case.

@retval NULL on failure


-Petri


>   */
>  void *odp_shm_addr(odp_shm_t shm);
> 
> 
>  /**
>   * Shared memory block info
> + * @note This is the only shared memory API function which accepts
> invalid
> + * shm handles (any bit value) without causing undefined behavior.
>   *
>   * @param[in]  shm   Block handle
>   * @param[out] info  Block info pointer for output
>   *
> - * @return 0 on success, otherwise non-zero
> + * @retval 0 on success
> + * @retval <0 on failure
>   */
>  int odp_shm_info(odp_shm_t shm, odp_shm_info_t *info);
> 
> --
> 1.9.1
> 
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp

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

Re: [lng-odp] [PATCHv5 11/18] api: odp_packet_io.h: updated return descriptions

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
> Sent: Tuesday, February 03, 2015 6:48 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv5 11/18] api: odp_packet_io.h: updated return
> descriptions
> 
> Updated doxygen descriptions, particularly the @return/@retval
> descriptions.
> No change of implementation necessary.
> 
> Signed-off-by: Ola Liljedahl 
> ---
> (This document/code contribution attached is provided under the terms of
> agreement LES-LTM-21309)
> 
>  include/odp/api/packet_io.h | 89 ++--
> -
>  Updated doxygen descriptions, particularly the @return/@retval
> descriptions.
>  No change of implementation necessary.
> 
>  1 file changed, 51 insertions(+), 38 deletions(-)
> 
> diff --git a/include/odp/api/packet_io.h b/include/odp/api/packet_io.h
> index 0c8af0c..3fa4063 100644
> --- a/include/odp/api/packet_io.h
> +++ b/include/odp/api/packet_io.h
> @@ -56,7 +56,8 @@ extern "C" {
>   * @param pool   Pool from which to allocate buffers for storing packets
>   *   received over this packet IO
>   *
> - * @return ODP packet IO handle or ODP_PKTIO_INVALID on error
> + * @return ODP packet IO handle
> + * @retval ODP_PKTIO_INVALID on failure
>   *
>   * @note dev name loop is specially pktio reserved name for
>   *device used for testing. Usually it's loop back
> @@ -67,110 +68,118 @@ odp_pktio_t odp_pktio_open(const char *dev,
> odp_pool_t pool);
>  /**
>   * Close an ODP packet IO instance
>   *
> - * @param id  ODP packet IO handle
> + * @param hdl  ODP packet IO handle
>   *
> - * @return 0 on success or -1 on error
> + * @retval 0 on success
> + * @retval <0 on failure
>   */
> -int odp_pktio_close(odp_pktio_t id);
> +int odp_pktio_close(odp_pktio_t hdl);
> 
>  /**
>   * Return a packet IO handle for an already open device
>   *
>   * @param dev Packet IO device name
>   *
> - * @return ODP packet IO handle or ODP_PKTIO_INVALID
> + * @return ODP packet IO handle
> + * @retval ODP_PKTIO_INVALID on failure
>   */
>  odp_pktio_t odp_pktio_lookup(const char *dev);
> 
>  /**
>   * Receive packets
>   *
> - * @param id  ODP packet IO handle
> + * @param hdl ODP packet IO handle
>   * @param pkt_table[] Storage for received packets (filled by function)
>   * @param len Length of pkt_table[], i.e. max number of pkts to
> receive
>   *
> - * @return Number of packets received or -1 on error
> + * @return Number of packets received
> + * @retval <0 on failure
>   */
> -int odp_pktio_recv(odp_pktio_t id, odp_packet_t pkt_table[], unsigned
> len);
> +int odp_pktio_recv(odp_pktio_t hdl, odp_packet_t pkt_table[], unsigned
> len);


As agreed, it's better to rename "id" to "pktio". And do that (preferably) on a 
separate patch. That can rename those couple of "pktio_in" in the bottom of the 
file.


About "unsigned len": if I remember correctly we agreed that functions that 
handle number of objects (not bytes or offset or chars) would have int both on 
input and output.


int odp_pktio_recv(odp_pktio_t hdl, odp_packet_t pkt_table[], int len);


int num = 10;
int ret;

ret = odp_pktio_recv(pktio, pkts[], num);

if (ret < num)
   ...


> 
>  /**
>   * Send packets
>   *
> - * @param id   ODP packet IO handle
> + * @param hdl  ODP packet IO handle
>   * @param pkt_table[]  Array of packets to send
>   * @param len  length of pkt_table[]
>   *
> - * @return Number of packets sent or -1 on error
> + * @return Number of packets sent
> + * @retval <0 on failure
>   */
> -int odp_pktio_send(odp_pktio_t id, odp_packet_t pkt_table[], unsigned
> len);
> +int odp_pktio_send(odp_pktio_t hdl, odp_packet_t pkt_table[], unsigned
> len);

Same here: int vs. unsigned ?


-Petri



> 
>  /**
>   * Set the default input queue to be associated with a pktio handle
>   *
> - * @param id ODP packet IO handle
> + * @param hdlODP packet IO handle
>   * @param queue default input queue set
> - * @return  0 on success or -1 on error
> + * @retval  0 on success
> + * @retval <0 on failure
>   */
> -int odp_pktio_inq_setdef(odp_pktio_t id, odp_queue_t queue);
> +int odp_pktio_inq_setdef(odp_pktio_t hdl, odp_queue_t queue);
> 
>  /**
>   * Get default input queue associated with a pktio handle
>   *
> - * @param id  ODP packet IO handle
> + * @param hdl ODP packet IO handle
>   *
> - * @return Default input queue set or ODP_QUEUE_INVALID on error
> + * @return Default input queue set
> + * @retval ODP_QUEUE_INVALID on failure
>   */
> -odp_queue_t odp_pktio_inq_getdef(odp_pktio_t id);
> +odp_queue_t odp_pktio_inq_getdef(odp_pktio_t hdl);
> 
>  /**
>   * Remove default input queue (if set)
>   *
> - * @param id  ODP packet IO handle
> + * @param hdl ODP packet IO handle
>   *
> - * @return 0 on success or -1 on error
> + * @retval 0 on success
> + * @retval <0 on failure
>   */
> -int odp_pktio_inq_remdef(odp_pktio_t

Re: [lng-odp] [PATCHv5 08/18] api: odp_init.h: updated return descriptions

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
> Sent: Tuesday, February 03, 2015 6:48 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv5 08/18] api: odp_init.h: updated return
> descriptions
> 
> Updated doxygen descriptions, particularly the @return/@retval
> descriptions.
> No change of implementation necessary.
> 
> Signed-off-by: Ola Liljedahl 
> ---
> (This document/code contribution attached is provided under the terms of
> agreement LES-LTM-21309)
> 
>  include/odp/api/init.h | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/include/odp/api/init.h b/include/odp/api/init.h
> index c73b321..c14769f 100644
> --- a/include/odp/api/init.h
> +++ b/include/odp/api/init.h
> @@ -66,8 +66,8 @@ typedef enum odp_log_level {
>   * @param[in] level   Log level
>   * @param[in] fmt printf-style message format
>   *
> - * @return The number of characters logged if succeeded. Otherwise
> returns
> - * a negative number.
> + * @return The number of characters logged on success
> + * @retval <0 on failure
>   */
>  int odp_override_log(odp_log_level_e level, const char *fmt, ...);
> 
> @@ -108,8 +108,8 @@ typedef struct odp_platform_init_t {
>   * @param[in] platform_params Those parameters that are passed without
>   * interpretation by the ODP API to the implementation.
>   *
> - * @retval 0 if successful
> - * @retval -1 on failure
> + * @retval 0 on success
> + * @retval <0 on failure
>   */
>  int odp_init_global(odp_init_t *params, odp_platform_init_t
> *platform_params);
> 
> @@ -133,8 +133,8 @@ int odp_init_global(odp_init_t *params,
> odp_platform_init_t *platform_params);
>   * @sa odp_init_global()
>   * @sa odp_term_local() which must have been called prior to this.
>   *
> - * @retval 0 if successful
> - * @retval -1 on failure
> + * @retval 0 on success
> + * @retval <0 on failure
>   */
>  int odp_term_global(void);
> 
> @@ -147,8 +147,8 @@ int odp_term_global(void);
>   * @sa odp_term_local()
>   * @sa odp_init_global() which must have been called prior to this.
>   *
> - * @retval 0 if successful
> - * @retval -1 on failure
> + * @retval 0 on success
> + * @retval <0 on failure
>   */
>  int odp_init_local(void);
> 
> @@ -170,8 +170,8 @@ int odp_init_local(void);
>   * @warning The unwinding of HW resources to allow them to be re used
> without reseting
>   * the device is a complex task that the application is expected to
> coordinate.
>   *
> - * @retval 1 if successful and more ODP thread exists
> - * @retval 0 if successful and it was the last ODP thread
> + * @retval 1 on success and more ODP threads exist
> + * @retval 0 on success and no more ODP threads exist

The existing documentation is better. The _last_ thread calls odp_term_global().

-Petri


>   * @retval -1 on failure
>   */
>  int odp_term_local(void);
> --
> 1.9.1
> 
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp

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

Re: [lng-odp] [PATCHv4 01/18] api: odp_cpumask.h: odp_cpumask_to_str() return chars written or error

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: ext Ola Liljedahl [mailto:ola.liljed...@linaro.org]
> Sent: Wednesday, February 04, 2015 2:03 PM
> To: Savolainen, Petri (NSN - FI/Espoo)
> Cc: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [PATCHv4 01/18] api: odp_cpumask.h:
> odp_cpumask_to_str() return chars written or error
> 
> On 4 February 2015 at 09:38, Savolainen, Petri (NSN - FI/Espoo)
>  wrote:
> >
> >
> >> -Original Message-
> >> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> >> boun...@lists.linaro.org] On Behalf Of ext Savolainen, Petri (NSN -
> >> FI/Espoo)
> >> Sent: Wednesday, February 04, 2015 10:31 AM
> >> To: ext Ola Liljedahl
> >> Cc: lng-odp@lists.linaro.org
> >> Subject: Re: [lng-odp] [PATCHv4 01/18] api: odp_cpumask.h:
> >> odp_cpumask_to_str() return chars written or error
> >>
> >> > >> diff --git a/include/odp/api/cpumask.h b/include/odp/api/cpumask.h
> >> > >> index 7482899..65969c3 100644
> >> > >> --- a/include/odp/api/cpumask.h
> >> > >> +++ b/include/odp/api/cpumask.h
> >> > >> @@ -18,12 +18,20 @@
> >> > >>  extern "C" {
> >> > >>  #endif
> >> > >>
> >> > >> +#include 
> >> > >> +#include 
> >> > >> +
> >> > >>  /** @addtogroup odp_scheduler
> >> > >>   *  CPU mask operations.
> >> > >>   *  @{
> >> > >>   */
> >> > >>
> >> > >> - /**
> >> > >> +/**
> >> > >> + * @def ODP_CPUMASK_BUFSIZE
> >> > >> + * Minimum size of output buffer for odp_cpumask_to_str()
> >> > >> + */
> >> > >
> >> > > ODP_CPUMASK_STRLEN is better. Better to use term string when it's a
> >> > character string.
> >>
> >> This one is missing from v5.
> >>
> >> Better name it STRLEN when it used for _to_str() and _from_str()
> function
> >> calls.
> >>
> >> char mask_str[ODP_CPUMASK_STRLEN];
> >> memset(mask_str, 0, sizeof(mask_str));
> >> odp_cpumask_to_str(mask, mask_str, sizeof(mask_str));
> >> odp_cpumask_from_str(mask, mask_str);
> >>
> >>
> >> -Petri
> >
> >
> > Or ODP_CPUMASK_STRLEN_MAX or ODP_CPUMASK_STR_MAX_CHARS ...
> >
> > The point is that, it's defining the max number of chars (not bytes)
> needed for the string output
> In C, "byte" means storage unit. A "char" is defined to take one
> storage unit (sizeof(char)==1).


Yeah, I know. But in common language byte refers to 8 bits. Normally it is like 
that and lot's of SW would break if it's not. We have both used chips with 16 
bit chars in the past.

My point is that "str" highlights to the user that it's a character string, and 
not a byte (==> 8-bit) buffer.

int8_t buf[BUF_SIZE]; // wrong, although it compiles due to "typedef char 
int8_t"

vs

char str[STR_SIZE];


-Petri


> See e.g. C - A Reference Manual; Harbison, Steele Jr. (chapter 6.1.1
> in the 4th edition)
> or http://c0x.coding-guidelines.com/6.5.3.4.html
> 
> So for an array of char (the odp_cpumask_to_str() uses "char *" to
> reference this array), there is no practical nor semantic difference
> between number of chars or number of bytes. We could have added some
> more words to the description (e.g. "size of output buffer in chars")
> but I think this would be redundant and potentially confusing (as the
> size in chars is the default and the output buffer is specified as an
> array of char).
> 
> In a case where the output buffer is of some non-char type, it makes
> sense to specify what type is used for the size if this is not
> otherwise obvious from the description.
> 
> 
> 
> > - and it cannot be mixed with the odp_cpumask_t (buffer) size.
> >
> >
> > -Petri
> >
> >
> >
> >
___
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCHv4 01/18] api: odp_cpumask.h: odp_cpumask_to_str() return chars written or error

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: ext Ola Liljedahl [mailto:ola.liljed...@linaro.org]
> Sent: Wednesday, February 04, 2015 12:32 PM
> To: Savolainen, Petri (NSN - FI/Espoo)
> Cc: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [PATCHv4 01/18] api: odp_cpumask.h:
> odp_cpumask_to_str() return chars written or error
> 
> On 4 February 2015 at 11:13, Savolainen, Petri (NSN - FI/Espoo)
>  wrote:
> >
> >
> >> -Original Message-
> >> From: ext Ola Liljedahl [mailto:ola.liljed...@linaro.org]
> >> Sent: Wednesday, February 04, 2015 11:50 AM
> >> To: Savolainen, Petri (NSN - FI/Espoo)
> >> Cc: lng-odp@lists.linaro.org
> >> Subject: Re: [lng-odp] [PATCHv4 01/18] api: odp_cpumask.h:
> >> odp_cpumask_to_str() return chars written or error
> >>
> >> On 4 February 2015 at 10:27, Savolainen, Petri (NSN - FI/Espoo)
> >>  wrote:
> >> >
> >> >
> >> >> -----Original Message-
> >> >> From: ext Ola Liljedahl [mailto:ola.liljed...@linaro.org]
> >> >> Sent: Wednesday, February 04, 2015 11:20 AM
> >> >> To: Savolainen, Petri (NSN - FI/Espoo)
> >> >> Cc: lng-odp@lists.linaro.org
> >> >> Subject: Re: [lng-odp] [PATCHv4 01/18] api: odp_cpumask.h:
> >> >> odp_cpumask_to_str() return chars written or error
> >> >>
> >> >> On 4 February 2015 at 09:38, Savolainen, Petri (NSN - FI/Espoo)
> >> >>  wrote:
> >> >> >
> >> >> >
> >> >> >> -Original Message-
> >> >> >> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> >> >> >> boun...@lists.linaro.org] On Behalf Of ext Savolainen, Petri (NSN
> -
> >> >> >> FI/Espoo)
> >> >> >> Sent: Wednesday, February 04, 2015 10:31 AM
> >> >> >> To: ext Ola Liljedahl
> >> >> >> Cc: lng-odp@lists.linaro.org
> >> >> >> Subject: Re: [lng-odp] [PATCHv4 01/18] api: odp_cpumask.h:
> >> >> >> odp_cpumask_to_str() return chars written or error
> >> >> >>
> >> >> >> > >> diff --git a/include/odp/api/cpumask.h
> >> b/include/odp/api/cpumask.h
> >> >> >> > >> index 7482899..65969c3 100644
> >> >> >> > >> --- a/include/odp/api/cpumask.h
> >> >> >> > >> +++ b/include/odp/api/cpumask.h
> >> >> >> > >> @@ -18,12 +18,20 @@
> >> >> >> > >>  extern "C" {
> >> >> >> > >>  #endif
> >> >> >> > >>
> >> >> >> > >> +#include 
> >> >> >> > >> +#include 
> >> >> >> > >> +
> >> >> >> > >>  /** @addtogroup odp_scheduler
> >> >> >> > >>   *  CPU mask operations.
> >> >> >> > >>   *  @{
> >> >> >> > >>   */
> >> >> >> > >>
> >> >> >> > >> - /**
> >> >> >> > >> +/**
> >> >> >> > >> + * @def ODP_CPUMASK_BUFSIZE
> >> >> >> > >> + * Minimum size of output buffer for odp_cpumask_to_str()
> >> >> >> > >> + */
> >> >> >> > >
> >> >> >> > > ODP_CPUMASK_STRLEN is better. Better to use term string when
> >> it's a
> >> >> >> > character string.
> >> >> But is it not a character string.
> >> >>
> >> >> The user specifies a buffer and a buffer size. The function writes a
> >> >> string into that buffer (if it fits into the buffer).
> >> >> The buffer then *contains* a string (which will be shorter that the
> >> >> buffer size value specified, e.g. because trailing CPU bits may not
> be
> >> >> set and also the string length does not include the terminating null
> >> >> char). But a string and a buffer are not the same thing.
> >> >>
> >> >> >>
> >> >> >> This one is missing from v5.
> >> >> >>
> >> >> >> Better name it STRLEN when it used for _to_str() and _from_str()
> >> >> function
> >> >> >> calls.
> >> >> I think this is a poor choice of name. The length of a string is

Re: [lng-odp] [PATCHv5 05/18] api: odp_buffer.h: undefined behavior description

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: ext Ola Liljedahl [mailto:ola.liljed...@linaro.org]
> Sent: Wednesday, February 04, 2015 12:01 PM
> To: Savolainen, Petri (NSN - FI/Espoo)
> Cc: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [PATCHv5 05/18] api: odp_buffer.h: undefined
> behavior description
> 
> On 4 February 2015 at 10:51, Savolainen, Petri (NSN - FI/Espoo)
>  wrote:
> >
> >
> >> -Original Message-
> >> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> >> boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
> >> Sent: Tuesday, February 03, 2015 6:48 PM
> >> To: lng-odp@lists.linaro.org
> >> Subject: [lng-odp] [PATCHv5 05/18] api: odp_buffer.h: undefined
> behavior
> >> description
> >>
> >> Documented API calls which are guaranteed to handle invalid/stale
> handles.
> >>
> >> Signed-off-by: Ola Liljedahl 
> >> ---
> >> (This document/code contribution attached is provided under the terms
> of
> >> agreement LES-LTM-21309)
> >>
> >>  include/odp/api/buffer.h | 4 +++-
> >>  1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/include/odp/api/buffer.h b/include/odp/api/buffer.h
> >> index 12b2f5a..1eb2e5a 100644
> >> --- a/include/odp/api/buffer.h
> >> +++ b/include/odp/api/buffer.h
> >> @@ -88,7 +88,9 @@ uint32_t odp_buffer_size(odp_buffer_t buf);
> >>  /**
> >>   * Tests if buffer is valid
> >>   *
> >> - * @param buf  Buffer handle
> >> + * @param buf  Buffer handle (possibly invalid)
> >> + * @note This is the only buffer API function which accepts invalid
> >> buffer
> >> + * handles (any bit value) without causing undefined behavior.
> >>   *
> >>   * @retval 1 Buffer handle represents a valid buffer.
> >>   * @retval 0 Buffer handle does not represent a valid buffer.
> >> --
> >
> > Originally, this and odp_packet_is_valid() were defined to enable full
> sanity check over the object. During debugging user could insert these on
> the way and (hopefully) catch the point where e.g. packet metadata (e.g.
> segment linking) was corrupted.
> Should we specify this "full sanity check of object" as well? That
> part is not obvious now and an ODP implementer could easily interpret
> "represents a valid buffer" in a less complete way.
> Perhaps this function needs more return values. E.g.
> @retval 0 Buffer handle is invalid (no further checks done)
> @retval 1 Buffer handle is valid but buffer is corrupted
> @retval 2 Buffer handle is valid and buffer seems correct

Another option is to set errno to indicate the reason of failure. Valid vs. 
broken buffer/packet is the most valuable information from the call. It's 
secondary to know why it's broken. No need to change return values or add errno 
for v1.0.

Also if this function needs to accept bad handles, I think it means that in 
general the handle structure/mapping to memory/etc have to be error tolerant, 
which we try to not force on other calls (by specifying undefined behavior on 
bad handles). To me it sounds all or nothing - either all buffer calls (that 
access only odp_buffer_t, no shared resources) have undefined behavior or non.

So, I'd leave the patch out from the set, and improve documentation (add 
"sanity check") with another patch.

> 
> >
> > So, I think this function could still crash on bad handles. Is there a
> use case that application would just want to check the handle validity
> (without crashing), but not the object sanity?
> I was thinking that some post-mortem dump code could iterate over all
> known (to the application) buffer and packet handles and save
> information about those. But in a crash situation, you can't really be
> sure that the handles you find are correct, e.g. could be stale
> handles so treated as invalid by an implementation. But you don't want
> to crash in your PMD code, in this case just save that this specific
> handle is invalid.

Good point, but maybe post mortem tools are a separate topic (vendor specific). 
Can we standardize what happens / can be done after crash? I guess not.

-Petri

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

Re: [lng-odp] [PATCHv4 01/18] api: odp_cpumask.h: odp_cpumask_to_str() return chars written or error

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: ext Ola Liljedahl [mailto:ola.liljed...@linaro.org]
> Sent: Wednesday, February 04, 2015 11:50 AM
> To: Savolainen, Petri (NSN - FI/Espoo)
> Cc: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [PATCHv4 01/18] api: odp_cpumask.h:
> odp_cpumask_to_str() return chars written or error
> 
> On 4 February 2015 at 10:27, Savolainen, Petri (NSN - FI/Espoo)
>  wrote:
> >
> >
> >> -Original Message-
> >> From: ext Ola Liljedahl [mailto:ola.liljed...@linaro.org]
> >> Sent: Wednesday, February 04, 2015 11:20 AM
> >> To: Savolainen, Petri (NSN - FI/Espoo)
> >> Cc: lng-odp@lists.linaro.org
> >> Subject: Re: [lng-odp] [PATCHv4 01/18] api: odp_cpumask.h:
> >> odp_cpumask_to_str() return chars written or error
> >>
> >> On 4 February 2015 at 09:38, Savolainen, Petri (NSN - FI/Espoo)
> >>  wrote:
> >> >
> >> >
> >> >> -Original Message-
> >> >> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> >> >> boun...@lists.linaro.org] On Behalf Of ext Savolainen, Petri (NSN -
> >> >> FI/Espoo)
> >> >> Sent: Wednesday, February 04, 2015 10:31 AM
> >> >> To: ext Ola Liljedahl
> >> >> Cc: lng-odp@lists.linaro.org
> >> >> Subject: Re: [lng-odp] [PATCHv4 01/18] api: odp_cpumask.h:
> >> >> odp_cpumask_to_str() return chars written or error
> >> >>
> >> >> > >> diff --git a/include/odp/api/cpumask.h
> b/include/odp/api/cpumask.h
> >> >> > >> index 7482899..65969c3 100644
> >> >> > >> --- a/include/odp/api/cpumask.h
> >> >> > >> +++ b/include/odp/api/cpumask.h
> >> >> > >> @@ -18,12 +18,20 @@
> >> >> > >>  extern "C" {
> >> >> > >>  #endif
> >> >> > >>
> >> >> > >> +#include 
> >> >> > >> +#include 
> >> >> > >> +
> >> >> > >>  /** @addtogroup odp_scheduler
> >> >> > >>   *  CPU mask operations.
> >> >> > >>   *  @{
> >> >> > >>   */
> >> >> > >>
> >> >> > >> - /**
> >> >> > >> +/**
> >> >> > >> + * @def ODP_CPUMASK_BUFSIZE
> >> >> > >> + * Minimum size of output buffer for odp_cpumask_to_str()
> >> >> > >> + */
> >> >> > >
> >> >> > > ODP_CPUMASK_STRLEN is better. Better to use term string when
> it's a
> >> >> > character string.
> >> But is it not a character string.
> >>
> >> The user specifies a buffer and a buffer size. The function writes a
> >> string into that buffer (if it fits into the buffer).
> >> The buffer then *contains* a string (which will be shorter that the
> >> buffer size value specified, e.g. because trailing CPU bits may not be
> >> set and also the string length does not include the terminating null
> >> char). But a string and a buffer are not the same thing.
> >>
> >> >>
> >> >> This one is missing from v5.
> >> >>
> >> >> Better name it STRLEN when it used for _to_str() and _from_str()
> >> function
> >> >> calls.
> >> I think this is a poor choice of name. The length of a string is the
> >> number of characters in the string (excluding the terminating null
> >> char). But we need to pass the buffer size.
> >>
> >> >>
> >> >> char mask_str[ODP_CPUMASK_STRLEN];
> >> >> memset(mask_str, 0, sizeof(mask_str));
> >> Why is the memset() here? It is not needed.
> >>
> >> >> odp_cpumask_to_str(mask, mask_str, sizeof(mask_str));
> >> >> odp_cpumask_from_str(mask, mask_str);
> >> Yes this is how it is done, before my patch and after my patch.
> >>
> >> >>
> >> >>
> >> >> -Petri
> >> >
> >> >
> >> > Or ODP_CPUMASK_STRLEN_MAX or ODP_CPUMASK_STR_MAX_CHARS ...
> >> >
> >> > The point is that, it's defining the max number of chars (not bytes)
> >> needed for the string output - and it cannot be mixed with the
> >> odp_cpumask_t (buffer) size.
> >> odp_cpumask_t has a separate well-defined type (no char bufs or void
> >> poin

Re: [lng-odp] [PATCHv5 05/18] api: odp_buffer.h: undefined behavior description

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
> Sent: Tuesday, February 03, 2015 6:48 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv5 05/18] api: odp_buffer.h: undefined behavior
> description
> 
> Documented API calls which are guaranteed to handle invalid/stale handles.
> 
> Signed-off-by: Ola Liljedahl 
> ---
> (This document/code contribution attached is provided under the terms of
> agreement LES-LTM-21309)
> 
>  include/odp/api/buffer.h | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/include/odp/api/buffer.h b/include/odp/api/buffer.h
> index 12b2f5a..1eb2e5a 100644
> --- a/include/odp/api/buffer.h
> +++ b/include/odp/api/buffer.h
> @@ -88,7 +88,9 @@ uint32_t odp_buffer_size(odp_buffer_t buf);
>  /**
>   * Tests if buffer is valid
>   *
> - * @param buf  Buffer handle
> + * @param buf  Buffer handle (possibly invalid)
> + * @note This is the only buffer API function which accepts invalid
> buffer
> + * handles (any bit value) without causing undefined behavior.
>   *
>   * @retval 1 Buffer handle represents a valid buffer.
>   * @retval 0 Buffer handle does not represent a valid buffer.
> --

Originally, this and odp_packet_is_valid() were defined to enable full sanity 
check over the object. During debugging user could insert these on the way and 
(hopefully) catch the point where e.g. packet metadata (e.g. segment linking) 
was corrupted.

So, I think this function could still crash on bad handles. Is there a use case 
that application would just want to check the handle validity (without 
crashing), but not the object sanity?

-Petri



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

Re: [lng-odp] [PATCHv4 01/18] api: odp_cpumask.h: odp_cpumask_to_str() return chars written or error

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: ext Ola Liljedahl [mailto:ola.liljed...@linaro.org]
> Sent: Wednesday, February 04, 2015 11:20 AM
> To: Savolainen, Petri (NSN - FI/Espoo)
> Cc: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [PATCHv4 01/18] api: odp_cpumask.h:
> odp_cpumask_to_str() return chars written or error
> 
> On 4 February 2015 at 09:38, Savolainen, Petri (NSN - FI/Espoo)
>  wrote:
> >
> >
> >> -Original Message-
> >> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> >> boun...@lists.linaro.org] On Behalf Of ext Savolainen, Petri (NSN -
> >> FI/Espoo)
> >> Sent: Wednesday, February 04, 2015 10:31 AM
> >> To: ext Ola Liljedahl
> >> Cc: lng-odp@lists.linaro.org
> >> Subject: Re: [lng-odp] [PATCHv4 01/18] api: odp_cpumask.h:
> >> odp_cpumask_to_str() return chars written or error
> >>
> >> > >> diff --git a/include/odp/api/cpumask.h b/include/odp/api/cpumask.h
> >> > >> index 7482899..65969c3 100644
> >> > >> --- a/include/odp/api/cpumask.h
> >> > >> +++ b/include/odp/api/cpumask.h
> >> > >> @@ -18,12 +18,20 @@
> >> > >>  extern "C" {
> >> > >>  #endif
> >> > >>
> >> > >> +#include 
> >> > >> +#include 
> >> > >> +
> >> > >>  /** @addtogroup odp_scheduler
> >> > >>   *  CPU mask operations.
> >> > >>   *  @{
> >> > >>   */
> >> > >>
> >> > >> - /**
> >> > >> +/**
> >> > >> + * @def ODP_CPUMASK_BUFSIZE
> >> > >> + * Minimum size of output buffer for odp_cpumask_to_str()
> >> > >> + */
> >> > >
> >> > > ODP_CPUMASK_STRLEN is better. Better to use term string when it's a
> >> > character string.
> But is it not a character string.
> 
> The user specifies a buffer and a buffer size. The function writes a
> string into that buffer (if it fits into the buffer).
> The buffer then *contains* a string (which will be shorter that the
> buffer size value specified, e.g. because trailing CPU bits may not be
> set and also the string length does not include the terminating null
> char). But a string and a buffer are not the same thing.
> 
> >>
> >> This one is missing from v5.
> >>
> >> Better name it STRLEN when it used for _to_str() and _from_str()
> function
> >> calls.
> I think this is a poor choice of name. The length of a string is the
> number of characters in the string (excluding the terminating null
> char). But we need to pass the buffer size.
> 
> >>
> >> char mask_str[ODP_CPUMASK_STRLEN];
> >> memset(mask_str, 0, sizeof(mask_str));
> Why is the memset() here? It is not needed.
> 
> >> odp_cpumask_to_str(mask, mask_str, sizeof(mask_str));
> >> odp_cpumask_from_str(mask, mask_str);
> Yes this is how it is done, before my patch and after my patch.
> 
> >>
> >>
> >> -Petri
> >
> >
> > Or ODP_CPUMASK_STRLEN_MAX or ODP_CPUMASK_STR_MAX_CHARS ...
> >
> > The point is that, it's defining the max number of chars (not bytes)
> needed for the string output - and it cannot be mixed with the
> odp_cpumask_t (buffer) size.
> odp_cpumask_t has a separate well-defined type (no char bufs or void
> pointers used when you are passing an odp_cpumask_t value), I see no
> risk for mixing it with ODP_CPUMASK_BUFSIZE.


If you reserve ODP_CPUMASK_BUFSIZE for the string API. What if we add 
odp_cpumask_to_u64(), odp_cpumask_to_u8(),odp_cpumask_to_buf(), etc API calls 
later on? It's better to reserve BUF for those buffers and use STR for strings 
(no matter if sting initialized or not before the call, output is still a 
string).

-Petri


 

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

Re: [lng-odp] [PATCHv2] api: fix odp_version_api_str()

[Savolainen, Petri (NSN - FI/Espoo)]

It's API function. It's important that user can log the used API version.

-Petri

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Maxim Uvarov
> Sent: Wednesday, February 04, 2015 10:46 AM
> To: Anders Roxell; Mike Holmes
> Cc: lng-odp
> Subject: Re: [lng-odp] [PATCHv2] api: fix odp_version_api_str()
> 
> odp_version_api_str() is API function or not? If it's api it has to be in
> api header. If it's implementation only helper it hat to be under linux-
> generic.
> 
> Maxim.
> 
> 
> 
> On 02/04/2015 01:48 AM, Anders Roxell wrote:
> > On 2015-02-03 11:28, Mike Holmes wrote:
> >> On 3 February 2015 at 11:12, Maxim Uvarov 
> wrote:
> >>
> >>> odp_version_api_str() has to be in API header while
> >>> odp_version_impl_str() should be in linux-generic.
> >>> That change fixes:
> >>> https://bugs.linaro.org/show_bug.cgi?id=1194
> >>>
> >>> Signed-off-by: Maxim Uvarov 
> >>>
> >> Reviewed-by: Mike Holmes 
> >>
> >> Clears the new test case patch "validation: add version string check"
> >> which should be added as insurance against this bug in the future
> before
> >> closing the bug
> > I think we can drop "static inline" to the version string function,
> > because checking for a version string is not time critical right?
> >
> > If we assume that its not time critical the diff below + Mikes
> validation
> > version string patch got it to pass and we hide more stuff from the
> > public doxygen clean API include/odp/api/*.h files.
> >
> > Cheers,
> > Anders
> >
> > $ git df
> > diff --git a/platform/linux-generic/include/odp/version.h
> b/platform/linux-generic/include/odp/version.h
> > index f29320a..2c557cc 100644
> > --- a/platform/linux-generic/include/odp/version.h
> > +++ b/platform/linux-generic/include/odp/version.h
> > @@ -23,11 +23,6 @@ extern "C" {
> >*  @{
> >*/
> >
> > -static inline const char *odp_version_api_str(void)
> > -{
> > -   return ODP_VERSION_API_STR;
> > -}
> > -
> >   /**
> >* @}
> >*/
> > diff --git a/platform/linux-generic/odp_impl.c b/platform/linux-
> generic/odp_impl.c
> > index ca3224d..23ab12d 100644
> > --- a/platform/linux-generic/odp_impl.c
> > +++ b/platform/linux-generic/odp_impl.c
> > @@ -28,6 +28,11 @@ const char *odp_version_impl_str(void)
> >  return ODP_VERSION_IMPL_STR;
> >   }
> >
> > +const char *odp_version_api_str(void)
> > +{
> > +   return ODP_VERSION_API_STR;
> > +}
> > +
> >   #ifdef __cplusplus
> >   }
> >   #endif
> 
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp

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

Re: [lng-odp] [PATCHv5 02/18] api: odp_pktio.h: odp_pktio_mac_addr() return chars written or error

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
> Sent: Tuesday, February 03, 2015 6:48 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv5 02/18] api: odp_pktio.h: odp_pktio_mac_addr()
> return chars written or error
> 
> Added define ODP_PKTIO_MACADDRSIZE which specifies the recommended
> output buffer size for odp_pktio_mac_addr().
> odp_pktio_mac_addr() takes output buffer size as input and returns
> number
> of chars written (on success), <0 on failure.
> Updated the implementation.
> Updated all usages in example and test programs.
> 
> Signed-off-by: Ola Liljedahl 
> ---
> (This document/code contribution attached is provided under the terms of
> agreement LES-LTM-21309)
> 
>  include/odp/api/packet_io.h  | 20 +--
> -
>  .../linux-generic/include/odp/plat/packet_io_types.h |  2 ++
>  platform/linux-generic/odp_packet_io.c   | 11 ++-
>  test/validation/odp_pktio.c  |  8 
>  4 files changed, 25 insertions(+), 16 deletions(-)
> 
> diff --git a/include/odp/api/packet_io.h b/include/odp/api/packet_io.h
> index da7bc3f..0c8af0c 100644
> --- a/include/odp/api/packet_io.h
> +++ b/include/odp/api/packet_io.h
> @@ -18,6 +18,7 @@
>  extern "C" {
>  #endif
> 
> +#include 
> 
>  /** @defgroup odp_packet_io ODP PACKET IO
>   *  Operations on a packet.
> @@ -39,6 +40,11 @@ extern "C" {
>   * odp_pktio_t value to indicate any port
>   */
> 
> +/*
> + * @def ODP_PKTIO_MACADDRSIZE
> + * Minimum size of output buffer for odp_pktio_mac_addr()

Should this be defined as ODP_PKTIO_MACADDRSIZE_MAX or similar. If the 
interface support two sizes this is the larger, although the configured and 
currently used size would be the smaller.

I want to avoid applications mixing this into protocol definitions like this

struct ether_hdr {
  uint8_t dst_mac[ODP_PKTIO_MACADDRSIZE];
  uint8_t src_mac[ODP_PKTIO_MACADDRSIZE];
...
};


> + */
> +
>  /**
>   * Open an ODP packet IO instance
>   *
> @@ -167,16 +173,16 @@ int odp_pktio_promisc_mode_set(odp_pktio_t id,
> odp_bool_t enable);
>  int odp_pktio_promisc_mode(odp_pktio_t id);
> 
>  /**
> - * Get the default MAC address of a packet IO interface.
> + * Get the native MAC address of a packet IO interface.

Why this is now defined as "native". Does it mean the address burned into the 
device. What if SW has overwritten that? Is it still native? Default is 
referring to the default address, whatever that maybe.

>   *
> - * @paramidODP packet IO handle.
> - * @param[out]   mac_addr  Storage for MAC address of the packet IO
> interface.
> - * @paramaddr_size Storage size for the address
> + * @paramhdl  ODP packet IO handle

This parameter renaming is not needed. All other packet_io.h API calls are 
using "id" here. Parameter naming should be constant throughout the API. Do not 
rename it in this patch.

I agree that "id" is not the best name for that parameter, but that's how it is 
in this API right now. We need another patch for renaming that over all the API 
calls.

Also "hdl" is not a good parameter name for an object. The name should link to 
the object type, like "pktio" (for odp_pktio_t type) in this case. Parameter 
list shows up in Doxygen function documentation without types.

-Petri


> + * @param[out]   mac_addr  Output buffer (use ODP_PKTIO_MACADDRSIZE)
> + * @param   size Size of output buffer
>   *
> - * @retval Number of bytes written on success, 0 on failure.
> + * @return Number of bytes written to buffer
> + * @retval <0 on failure
>   */
> -size_t odp_pktio_mac_addr(odp_pktio_t id, void *mac_addr,
> -   size_t addr_size);
> +ssize_t odp_pktio_mac_addr(odp_pktio_t hdl, void *mac_addr, ssize_t
> size);
> 
>  /**
>   * Setup per-port default class-of-service.
> diff --git a/platform/linux-generic/include/odp/plat/packet_io_types.h
> b/platform/linux-generic/include/odp/plat/packet_io_types.h
> index a6bbacf..61dca13 100644
> --- a/platform/linux-generic/include/odp/plat/packet_io_types.h
> +++ b/platform/linux-generic/include/odp/plat/packet_io_types.h
> @@ -23,6 +23,8 @@ extern "C" {
>   *  @{
>   */
> 
> +#define ODP_PKTIO_MACADDRSIZE 16
> +
>  typedef uint32_t odp_pktio_t;
> 
>  #define ODP_PKTIO_INVALID 0
> diff --git a/platform/linux-generic/odp_packet_io.c b/platform/linux-
> generic/odp_packet_io.c
> index bdb690e..f156dd3 100644
> --- a/platform/linux-generic/odp_packet_io.c
> +++ b/platform/linux-generic/odp_packet_io.c
> @@ -798,18 +798,19 @@ int odp_pktio_promisc_mode(odp_pktio_t id)
>  }
> 
> 
> -size_t odp_pktio_mac_addr(odp_pktio_t id, void *mac_addr,
> -size_t addr_size)
> +ssize_t odp_pktio_mac_addr(odp_pktio_t id, void *mac_addr, ssize_t
> addr_size)
>  {
>   pktio_entry_t *entry;
> 
> - if (addr_size < ETH_ALEN)
> - return 0;
> + if (addr_size < ETH_ALEN)

Re: [lng-odp] [PATCHv4 01/18] api: odp_cpumask.h: odp_cpumask_to_str() return chars written or error

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Savolainen, Petri (NSN -
> FI/Espoo)
> Sent: Wednesday, February 04, 2015 10:31 AM
> To: ext Ola Liljedahl
> Cc: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [PATCHv4 01/18] api: odp_cpumask.h:
> odp_cpumask_to_str() return chars written or error
> 
> > >> diff --git a/include/odp/api/cpumask.h b/include/odp/api/cpumask.h
> > >> index 7482899..65969c3 100644
> > >> --- a/include/odp/api/cpumask.h
> > >> +++ b/include/odp/api/cpumask.h
> > >> @@ -18,12 +18,20 @@
> > >>  extern "C" {
> > >>  #endif
> > >>
> > >> +#include 
> > >> +#include 
> > >> +
> > >>  /** @addtogroup odp_scheduler
> > >>   *  CPU mask operations.
> > >>   *  @{
> > >>   */
> > >>
> > >> - /**
> > >> +/**
> > >> + * @def ODP_CPUMASK_BUFSIZE
> > >> + * Minimum size of output buffer for odp_cpumask_to_str()
> > >> + */
> > >
> > > ODP_CPUMASK_STRLEN is better. Better to use term string when it's a
> > character string.
> 
> This one is missing from v5.
> 
> Better name it STRLEN when it used for _to_str() and _from_str() function
> calls.
> 
> char mask_str[ODP_CPUMASK_STRLEN];
> memset(mask_str, 0, sizeof(mask_str));
> odp_cpumask_to_str(mask, mask_str, sizeof(mask_str));
> odp_cpumask_from_str(mask, mask_str);
> 
> 
> -Petri


Or ODP_CPUMASK_STRLEN_MAX or ODP_CPUMASK_STR_MAX_CHARS ...

The point is that, it's defining the max number of chars (not bytes) needed for 
the string output - and it cannot be mixed with the odp_cpumask_t (buffer) size.


-Petri





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

Re: [lng-odp] [PATCHv4 01/18] api: odp_cpumask.h: odp_cpumask_to_str() return chars written or error

[Savolainen, Petri (NSN - FI/Espoo)]

> >> diff --git a/include/odp/api/cpumask.h b/include/odp/api/cpumask.h
> >> index 7482899..65969c3 100644
> >> --- a/include/odp/api/cpumask.h
> >> +++ b/include/odp/api/cpumask.h
> >> @@ -18,12 +18,20 @@
> >>  extern "C" {
> >>  #endif
> >>
> >> +#include 
> >> +#include 
> >> +
> >>  /** @addtogroup odp_scheduler
> >>   *  CPU mask operations.
> >>   *  @{
> >>   */
> >>
> >> - /**
> >> +/**
> >> + * @def ODP_CPUMASK_BUFSIZE
> >> + * Minimum size of output buffer for odp_cpumask_to_str()
> >> + */
> >
> > ODP_CPUMASK_STRLEN is better. Better to use term string when it's a
> character string.

This one is missing from v5.

Better name it STRLEN when it used for _to_str() and _from_str() function calls.

char mask_str[ODP_CPUMASK_STRLEN];
memset(mask_str, 0, sizeof(mask_str));
odp_cpumask_to_str(mask, mask_str, sizeof(mask_str));
odp_cpumask_from_str(mask, mask_str);


-Petri



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

Re: [lng-odp] [PATCH v2 1/4] api: cpu: Added cpu.h

[Savolainen, Petri (NSN - FI/Espoo)]

Sorry about top posting … just cannot reply cleanly on HTML mails.

Mike, I have seen same thing happening on your patches. On a patch series, one 
patch modifies a file in one direction and another patch modifies the same in 
other direction, but as long as the end result is OK - I have not minded. Maybe 
we have a new rule then on top of check patch and make check passing on each 
step: “each patch set must be optimized for minimum number of changes per file”.

Sure, I can fix it if it’s worth of the delay.

-Petri


From: ext Mike Holmes [mailto:mike.hol...@linaro.org]
Sent: Wednesday, February 04, 2015 12:59 AM
To: Bill Fischofer
Cc: Anders Roxell; Savolainen, Petri (NSN - FI/Espoo); LNG ODP Mailman List
Subject: Re: [lng-odp] [PATCH v2 1/4] api: cpu: Added cpu.h



On 3 February 2015 at 17:10, Bill Fischofer 
mailto:bill.fischo...@linaro.org>> wrote:
My review simply says I'm happy with it.  Others can NAK it if they choose.

On Tue, Feb 3, 2015 at 3:54 PM, Anders Roxell 
mailto:anders.rox...@linaro.org>> wrote:
On 2015-02-03 11:16, Bill Fischofer wrote:
> For this series:
>
> Reviewed-by: Bill Fischofer 
> mailto:bill.fischo...@linaro.org>>
>
> On Tue, Feb 3, 2015 at 5:25 AM, Savolainen, Petri (NSN - FI/Espoo) <
> petri.savolai...@nsn.com<mailto:petri.savolai...@nsn.com>> wrote:
>
> >
> >

[...]

> > > >> + *
> > > >> + * CPU number where the thread is currently running. CPU numbering is
> > > system
> > > >> + * specific.
> > > >> + *
> > > >> + * @return CPU number
> > > >> + */
> > > >> +int odp_cpu(void);
> > > > Why not call thus function odp_cpu_num()? (or odp_cpu_number)?
> > > > "odp_cpu" is missing something and does not lead to direct
> > > > understanding of what the function does or returns.
> > >
> > > I become odp_cpu_id() in the second patch.
> > > Why not to name it like this in the first patch?
> >
> > I rebased the second commit (should have rebased the first). The commit
> > history is not perfect, but I think we can live with that.

Why do we think this is good enough when others have to redo their
patches?

nack: I don't think it is ok to accept something when we know it is incorrect.



Cheers,
Anders


___
lng-odp mailing list
lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org>
http://lists.linaro.org/mailman/listinfo/lng-odp



--
Mike Holmes
Linaro  Sr Technical Manager
LNG - ODP
___
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCHv4 01/18] api: odp_cpumask.h: odp_cpumask_to_str() return chars written or error

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
> Sent: Tuesday, February 03, 2015 4:53 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv4 01/18] api: odp_cpumask.h:
> odp_cpumask_to_str() return chars written or error
> 
> Add define ODP_CPUMASK_BUFSIZE for minimum output buffer size for
> odp_cpumask_to_str().
> odp_cpumask_to_str() takes output buffer size as input and returns number
> of chars written (on success), <0 on failure.
> Updated the implementation.
> Updated all usages in example and test programs.
> 
> Signed-off-by: Ola Liljedahl 
> ---
> (This document/code contribution attached is provided under the terms of
> agreement LES-LTM-21309)
> 
>  example/generator/odp_generator.c  |  4 ++--
>  example/ipsec/odp_ipsec.c  |  4 ++--
>  example/l2fwd/odp_l2fwd.c  |  4 ++--
>  example/packet/odp_pktio.c |  4 ++--
>  example/timer/odp_timer_test.c |  4 ++--
>  include/odp/api/cpumask.h  | 23 ++---
> --
>  .../linux-generic/include/odp/plat/cpumask_types.h |  5 +
>  platform/linux-generic/odp_cpumask.c   | 26 +
> -
>  test/api_test/odp_common.c |  4 ++--
>  test/performance/odp_scheduling.c  |  4 ++--
>  10 files changed, 51 insertions(+), 31 deletions(-)
> 
> diff --git a/example/generator/odp_generator.c
> b/example/generator/odp_generator.c
> index 03dab50..2433cb6 100644
> --- a/example/generator/odp_generator.c
> +++ b/example/generator/odp_generator.c
> @@ -545,7 +545,7 @@ int main(int argc, char *argv[])
>   int i;
>   odp_shm_t shm;
>   odp_cpumask_t cpumask;
> - char cpumaskstr[64];
> + char cpumaskstr[ODP_CPUMASK_BUFSIZE];
>   odp_pool_param_t params;
> 
>   /* Init ODP before calling anything else */
> @@ -596,7 +596,7 @@ int main(int argc, char *argv[])
>* Start mapping thread from CPU #1
>*/
>   num_workers = odph_linux_cpumask_default(&cpumask, num_workers);
> - odp_cpumask_to_str(&cpumask, cpumaskstr, sizeof(cpumaskstr));
> + (void)odp_cpumask_to_str(&cpumask, cpumaskstr, sizeof(cpumaskstr));
> 
>   printf("num worker threads: %i\n", num_workers);
>   printf("first CPU:  %i\n", odp_cpumask_first(&cpumask));
> diff --git a/example/ipsec/odp_ipsec.c b/example/ipsec/odp_ipsec.c
> index 03f2419..869fd3a 100644
> --- a/example/ipsec/odp_ipsec.c
> +++ b/example/ipsec/odp_ipsec.c
> @@ -1193,7 +1193,7 @@ main(int argc, char *argv[])
>   int stream_count;
>   odp_shm_t shm;
>   odp_cpumask_t cpumask;
> - char cpumaskstr[64];
> + char cpumaskstr[ODP_CPUMASK_BUFSIZE];
>   odp_pool_param_t params;
> 
>   /* Init ODP before calling anything else */
> @@ -1242,7 +1242,7 @@ main(int argc, char *argv[])
>* Start mapping thread from CPU #1
>*/
>   num_workers = odph_linux_cpumask_default(&cpumask, num_workers);
> - odp_cpumask_to_str(&cpumask, cpumaskstr, sizeof(cpumaskstr));
> + (void)odp_cpumask_to_str(&cpumask, cpumaskstr, sizeof(cpumaskstr));
> 
>   printf("num worker threads: %i\n", num_workers);
>   printf("first CPU:  %i\n", odp_cpumask_first(&cpumask));
> diff --git a/example/l2fwd/odp_l2fwd.c b/example/l2fwd/odp_l2fwd.c
> index 7a520fb..e22ec0c 100644
> --- a/example/l2fwd/odp_l2fwd.c
> +++ b/example/l2fwd/odp_l2fwd.c
> @@ -294,7 +294,7 @@ int main(int argc, char *argv[])
>   int num_workers;
>   odp_shm_t shm;
>   odp_cpumask_t cpumask;
> - char cpumaskstr[64];
> + char cpumaskstr[ODP_CPUMASK_BUFSIZE];
>   odp_pool_param_t params;
> 
>   /* Init ODP before calling anything else */
> @@ -336,7 +336,7 @@ int main(int argc, char *argv[])
>* Start mapping thread from CPU #1
>*/
>   num_workers = odph_linux_cpumask_default(&cpumask, num_workers);
> - odp_cpumask_to_str(&cpumask, cpumaskstr, sizeof(cpumaskstr));
> + (void)odp_cpumask_to_str(&cpumask, cpumaskstr, sizeof(cpumaskstr));
> 
>   printf("num worker threads: %i\n", num_workers);
>   printf("first CPU:  %i\n", odp_cpumask_first(&cpumask));
> diff --git a/example/packet/odp_pktio.c b/example/packet/odp_pktio.c
> index 28ed98c..e38029a 100644
> --- a/example/packet/odp_pktio.c
> +++ b/example/packet/odp_pktio.c
> @@ -287,7 +287,7 @@ int main(int argc, char *argv[])
>   int i;
>   int cpu;
>   odp_cpumask_t cpumask;
> - char cpumaskstr[64];
> + char cpumaskstr[ODP_CPUMASK_BUFSIZE];
>   odp_pool_param_t params;
> 
>   args = calloc(1, sizeof(args_t));
> @@ -324,7 +324,7 @@ int main(int argc, char *argv[])
>* Start mapping thread from CPU #1
>*/
>   num_workers = odph_linux_cpumask_default(&cpumask, num_workers);
> - odp_cpumask_to_str(&cpumask, cpumaskstr

Re: [lng-odp] [PATCHv5 00/19] Add Strong Typing for ODP Abstract Types

[Savolainen, Petri (NSN - FI/Espoo)]

APIs OK.

Reviewed-by: Petri Savolainen 



> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Bill Fischofer
> Sent: Tuesday, February 03, 2015 6:45 AM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv5 00/19] Add Strong Typing for ODP Abstract
> Types
> 
> This patch series adds strong typing support for ODP abstract types. This
> prevents incorrect types from being used with ODP APIs. Misuse of types
> will
> now result in a compile-time error.
> 
> To allow handles to be printed for diagnostic purposes the following new
> APIs
> are added that have the signatures:
> 
> uint64_t odp_buffer_to_u64(odp_buffer_t hdl);
> uint64_t odp_cos_to_u64(odp_cos_t hdl);
> uint64_t odp_crypto_compl_to_u64(odp_crypto_compl_t hdl);
> uint64_t odp_crypto_session_to_u64(odp_crypto_session_t hdl);
> uint64_t odp_pmr_to_u64(odp_pmr_t_hdl);
> uint64_t odp_pmr_set_to_u64(odp_pmr_set_t hdl);
> uint64_t odp_event_to_u64(odp_event_t hdl);
> uint64_t odp_packet_to_u64(odp_packet_t hdl);
> uint64_t odp_packet_seg_to_u64(odp_packet_seg_t_print);
> uint64_t odp_pool_to_u64(odp_pool_t hdl);
> uint64_t odp_pktio_to_u64(odp_pktio_t hdl);
> uint64_t odp_queue_to_u64(odp_queue_t hdl);
> uint64_t odp_shm_to_u64(odp_shm_t hdl);
> 
> The output of these routines should be printed using the C99 PRIu64 format
> code, and examples are updated to this convention.
> 
> Patch change history:
> v2 - Adds print functions for the remaining public ODP types. It is also
> rebased to apply on the 0.10.0 release of ODP.
> 
> v3 - Corrects the definition of odp_buffer_bits to ensure that correct
> fields
> are referenced on both big and little endian systems.
> 
> v4 - Add missing strong typing support for odp_crypto_session_t and
> odp_crypto_compl_t types.
> 
> v5 - Change display function names from odp__t_print() to
> odp__to_u64(). Split out API changes from linux-generic
> implementation
> changes.
> 
> Petri: Please review these new APIs. All other changes as a result of this
> patch are internal and transparent to ODP applications.
> 
> Bill Fischofer (19):
>   api: buffers: add strong typing handle diplay function
>   api: classification: add strong typing handle display functions
>   api: crypto: add strong typing handle display functions
>   api: events: add strong typing handle display function
>   api: packets: add strong typing handle display function
>   api: pktio: add strong typing handle display function
>   api: pool: add strong typing handle display function
>   api: queues: add strong typing handle display function
>   api: shm: add strong typing handle display function
>   linux-generic: add base macros for strong typing support
>   linux-generic: buffers: add strong typing support
>   linux-generic: classification: add strong typing support
>   linux-generic: crypto: add strong typing support
>   linux-generic: events: add strong typing support
>   linux-generic: pktio: add strong typing support
>   linux-generic: packets: add strong typing support
>   linux-generic: pool: add strong typing support
>   linux-generic: queues: add strong typing support
>   linux-generic: shm: add strong typing support
> 
>  example/generator/odp_generator.c  | 12 +++--
>  example/ipsec/odp_ipsec.c  | 18 +---
>  example/l2fwd/odp_l2fwd.c  | 11 +++--
>  example/packet/odp_pktio.c | 22 ++
>  include/odp/api/buffer.h   | 13 ++
>  include/odp/api/classification.h   | 44 -
> --
>  include/odp/api/crypto.h   | 26 +++
>  include/odp/api/event.h| 12 +
>  include/odp/api/packet.h   | 25 +++
>  include/odp/api/packet_io.h| 12 +
>  include/odp/api/pool.h | 13 ++
>  include/odp/api/queue.h| 13 ++
>  include/odp/api/shared_memory.h| 13 ++
>  platform/linux-generic/Makefile.am |  1 +
>  .../linux-generic/include/odp/plat/buffer_types.h  | 15 +--
>  .../include/odp/plat/classification_types.h| 34 ---
>  .../linux-generic/include/odp/plat/crypto_types.h  | 13 +-
>  .../linux-generic/include/odp/plat/event_types.h   | 14 --
>  .../include/odp/plat/packet_io_types.h | 15 +--
>  .../linux-generic/include/odp/plat/packet_types.h  | 24 +++---
>  .../linux-generic/include/odp/plat/pool_types.h| 13 +-
>  .../linux-generic/include/odp/plat/queue_types.h   | 14 --
>  .../include/odp/plat/shared_memory_types.h | 13 +-
>  .../linux-generic/include/odp/plat/strong_types.h  | 38 
>  .../linux-generic/include/odp_buffer_inlines.h | 16 ---
>  .../linux-generic/include/odp_buffer_internal.h| 31 ++---
> 

Re: [lng-odp] [PATCHv2] api: odp_event.h: remove ODP_EVENT_TYPE_INVALID

[Savolainen, Petri (NSN - FI/Espoo)]

Reviewed-by: Petri Savolainen 

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
> Sent: Tuesday, February 03, 2015 1:04 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv2] api: odp_event.h: remove
> ODP_EVENT_TYPE_INVALID
> 
> Remove ODP_EVENT_TYPE_INVALID from odp_event.h.
> Update description of odp_event_type(), is does not return
> ODP_EVENT_TYPE_INVALID.
> Remove ODP_POOL_TYPE_INVALID from odp_pool.h. It was defined to
> ODP_EVENT_TYPE_INVALID.
> 
> Signed-off-by: Ola Liljedahl 
> ---
> (This document/code contribution attached is provided under the terms of
> agreement LES-LTM-21309)
> 
> Changed description of odp_event_type() after review by Petri S.
> 
>  include/odp/api/event.h   | 9 ++---
>  include/odp/api/pool.h| 2 --
>  platform/linux-generic/include/odp/plat/event_types.h | 1 -
>  3 files changed, 2 insertions(+), 10 deletions(-)
> 
> diff --git a/include/odp/api/event.h b/include/odp/api/event.h
> index 50c031a..d0413b9 100644
> --- a/include/odp/api/event.h
> +++ b/include/odp/api/event.h
> @@ -36,11 +36,6 @@ extern "C" {
>   */
> 
>  /**
> - * @def ODP_EVENT_TYPE_INVALID
> - * Invalid event type
> - */
> -
> -/**
>   * @def ODP_EVENT_BUFFER
>   * Buffer event
>   */
> @@ -61,11 +56,11 @@ extern "C" {
>   */
> 
>  /**
> - * Event type
> + * Get event type
>   *
>   * @param eventEvent handle
>   *
> - * @return Event type or ODP_EVENT_TYPE_INVALID
> + * @return Event type
>   */
>  int odp_event_type(odp_event_t event);
> 
> diff --git a/include/odp/api/pool.h b/include/odp/api/pool.h
> index 1582102..d09d92e 100644
> --- a/include/odp/api/pool.h
> +++ b/include/odp/api/pool.h
> @@ -79,8 +79,6 @@ typedef struct odp_pool_param_t {
> 
>  } odp_pool_param_t;
> 
> -/** Invalid pool type */
> -#define ODP_POOL_TYPE_INVALID ODP_EVENT_TYPE_INVALID
>  /** Packet pool*/
>  #define ODP_POOL_PACKET   ODP_EVENT_PACKET
>  /** Buffer pool */
> diff --git a/platform/linux-generic/include/odp/plat/event_types.h
> b/platform/linux-generic/include/odp/plat/event_types.h
> index 4a0756b..c98d416 100644
> --- a/platform/linux-generic/include/odp/plat/event_types.h
> +++ b/platform/linux-generic/include/odp/plat/event_types.h
> @@ -30,7 +30,6 @@ typedef odp_buffer_t odp_event_t;
> 
>  #define ODP_EVENT_INVALID ODP_BUFFER_INVALID
> 
> -#define ODP_EVENT_TYPE_INVALID (-1)
>  #define ODP_EVENT_BUFFER 1
>  #define ODP_EVENT_PACKET 2
>  #define ODP_EVENT_TIMEOUT3
> --
> 1.9.1
> 
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp

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

Re: [lng-odp] [PATCH v2 1/4] api: cpu: Added cpu.h

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: ext Taras Kondratiuk [mailto:taras.kondrat...@linaro.org]
> Sent: Tuesday, February 03, 2015 1:19 PM
> To: Ola Liljedahl; Petri Savolainen
> Cc: LNG ODP Mailman List
> Subject: Re: [lng-odp] [PATCH v2 1/4] api: cpu: Added cpu.h
> 
> On 02/03/2015 01:07 PM, Ola Liljedahl wrote:
> > On 3 February 2015 at 11:59, Petri Savolainen
> >  wrote:
> >> This file contains cpu related API calls. The calls are
> >> renames from odp_thread_cpu() and odp_sys_cpu_count().
> >>
> >> Signed-off-by: Petri Savolainen 
> >> ---
> >>   include/odp.h|  1 +
> >>   include/odp/api/cpu.h| 54
> 
> >>   platform/linux-generic/Makefile.am   |  2 ++
> >>   platform/linux-generic/include/odp/cpu.h | 26 +++
> >>   4 files changed, 83 insertions(+)
> >>   create mode 100644 include/odp/api/cpu.h
> >>   create mode 100644 platform/linux-generic/include/odp/cpu.h
> >>
> >> diff --git a/include/odp.h b/include/odp.h
> >> index 30bed8e..99e01eb 100644
> >> --- a/include/odp.h
> >> +++ b/include/odp.h
> >> @@ -27,6 +27,7 @@ extern "C" {
> >>   #include 
> >>   #include 
> >>   #include 
> >> +#include 
> >>   #include 
> >>   #include 
> >>   #include 
> >> diff --git a/include/odp/api/cpu.h b/include/odp/api/cpu.h
> >> new file mode 100644
> >> index 000..16461a3
> >> --- /dev/null
> >> +++ b/include/odp/api/cpu.h
> >> @@ -0,0 +1,54 @@
> >> +/* Copyright (c) 2015, Linaro Limited
> >> + * All rights reserved.
> >> + *
> >> + * SPDX-License-Identifier: BSD-3-Clause
> >> + */
> >> +
> >> +
> >> +/**
> >> + * @file
> >> + *
> >> + * ODP CPU API
> >> + */
> >> +
> >> +#ifndef ODP_CPU_H_
> >> +#define ODP_CPU_H_
> >> +
> >> +#ifdef __cplusplus
> >> +extern "C" {
> >> +#endif
> >> +
> >> +/** @defgroup odp_cpu ODP CPU
> >> + *  @{
> >> + */
> >> +
> >> +
> >> +/**
> >> + * CPU number
> >> + *
> >> + * CPU number where the thread is currently running. CPU numbering is
> system
> >> + * specific.
> >> + *
> >> + * @return CPU number
> >> + */
> >> +int odp_cpu(void);
> > Why not call thus function odp_cpu_num()? (or odp_cpu_number)?
> > "odp_cpu" is missing something and does not lead to direct
> > understanding of what the function does or returns.
> 
> I become odp_cpu_id() in the second patch.
> Why not to name it like this in the first patch?

I rebased the second commit (should have rebased the first). The commit history 
is not perfect, but I think we can live with that.

-Petri






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

Re: [lng-odp] [PATCH] api: odp_event.h: remove ODP_EVENT_TYPE_INVALID

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: ext Ola Liljedahl [mailto:ola.liljed...@linaro.org]
> Sent: Tuesday, February 03, 2015 10:49 AM
> To: Savolainen, Petri (NSN - FI/Espoo)
> Cc: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [PATCH] api: odp_event.h: remove
> ODP_EVENT_TYPE_INVALID
> 
> On 3 February 2015 at 09:15, Savolainen, Petri (NSN - FI/Espoo)
>  wrote:
> >
> >
> >> -Original Message-
> >> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> >> boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
> >> Sent: Monday, February 02, 2015 6:01 PM
> >> To: lng-odp@lists.linaro.org
> >> Subject: [lng-odp] [PATCH] api: odp_event.h: remove
> ODP_EVENT_TYPE_INVALID
> >>
> >> Remove ODP_EVENT_TYPE_INVALID from odp_event.h.
> >> Update description of odp_event_type(), is does not return
> >> ODP_EVENT_TYPE_INVALID.
> >> Remove ODP_POOL_TYPE_INVALID from odp_pool.h. It was defined to
> >> ODP_EVENT_TYPE_INVALID.
> >>
> >> Signed-off-by: Ola Liljedahl 
> >> ---
> >> (This document/code contribution attached is provided under the terms
> of
> >> agreement LES-LTM-21309)
> >>
> >>  include/odp/api/event.h   | 9 ++---
> >>  include/odp/api/pool.h| 2 --
> >>  platform/linux-generic/include/odp/plat/event_types.h | 1 -
> >>  3 files changed, 2 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/include/odp/api/event.h b/include/odp/api/event.h
> >> index 50c031a..ce97bdc 100644
> >> --- a/include/odp/api/event.h
> >> +++ b/include/odp/api/event.h
> >> @@ -36,11 +36,6 @@ extern "C" {
> >>   */
> >>
> >>  /**
> >> - * @def ODP_EVENT_TYPE_INVALID
> >> - * Invalid event type
> >> - */
> >> -
> >> -/**
> >>   * @def ODP_EVENT_BUFFER
> >>   * Buffer event
> >>   */
> >> @@ -61,11 +56,11 @@ extern "C" {
> >>   */
> >>
> >>  /**
> >> - * Event type
> >> + * Return type of event
> >
> > Don't change the Doxygen brief description. Almost every function return
> something, no need to mention that in the brief description. The detail
> description is there for full description/sentences.
> Most functions have side effects and it is the side effect you are
> after. What they return is normally just a status code or other
> information on how successful they were (e.g. number of items
> processed or written etc) in that side effect. This function *only*
> returns something with no side effects. Thus the difference in
> description.

When you browse or search through the doxygen API documentation. It would be 
nice to find the keyword pair "event type" easily (and consistently).

Currently most "get" type functions are labeled either "Type_x param_y" or "Get 
type_x param_y" (in brief description). You can change it to "Get event type", 
or leave as is. But do not change to "Return param_y of type_x".

-Petri

 

> 
> >
> > Otherwise OK.
> >
> > -Petri
> >
> >
> >>   *
> >>   * @param eventEvent handle
> >>   *
> >> - * @return Event type or ODP_EVENT_TYPE_INVALID
> >> + * @return Event type
> >>   */
> >>  int odp_event_type(odp_event_t event);
> >>
> >> diff --git a/include/odp/api/pool.h b/include/odp/api/pool.h
> >> index 1582102..d09d92e 100644
> >> --- a/include/odp/api/pool.h
> >> +++ b/include/odp/api/pool.h
> >> @@ -79,8 +79,6 @@ typedef struct odp_pool_param_t {
> >>
> >>  } odp_pool_param_t;
> >>
> >> -/** Invalid pool type */
> >> -#define ODP_POOL_TYPE_INVALID ODP_EVENT_TYPE_INVALID
> >>  /** Packet pool*/
> >>  #define ODP_POOL_PACKET   ODP_EVENT_PACKET
> >>  /** Buffer pool */
> >> diff --git a/platform/linux-generic/include/odp/plat/event_types.h
> >> b/platform/linux-generic/include/odp/plat/event_types.h
> >> index 4a0756b..c98d416 100644
> >> --- a/platform/linux-generic/include/odp/plat/event_types.h
> >> +++ b/platform/linux-generic/include/odp/plat/event_types.h
> >> @@ -30,7 +30,6 @@ typedef odp_buffer_t odp_event_t;
> >>
> >>  #define ODP_EVENT_INVALID ODP_BUFFER_INVALID
> >>
> >> -#define ODP_EVENT_TYPE_INVALID (-1)
> >>  #define ODP_EVENT_BUFFER 1
> >>  #define ODP_EVENT_PACKET 2
> >>  #define ODP_EVENT_TIMEOUT3
> >> --
> >> 1.9.1
> >>
> >>
> >> ___
> >> lng-odp mailing list
> >> lng-odp@lists.linaro.org
> >> http://lists.linaro.org/mailman/listinfo/lng-odp
___
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH] api: odp_event.h: remove ODP_EVENT_TYPE_INVALID

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
> Sent: Monday, February 02, 2015 6:01 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCH] api: odp_event.h: remove ODP_EVENT_TYPE_INVALID
> 
> Remove ODP_EVENT_TYPE_INVALID from odp_event.h.
> Update description of odp_event_type(), is does not return
> ODP_EVENT_TYPE_INVALID.
> Remove ODP_POOL_TYPE_INVALID from odp_pool.h. It was defined to
> ODP_EVENT_TYPE_INVALID.
> 
> Signed-off-by: Ola Liljedahl 
> ---
> (This document/code contribution attached is provided under the terms of
> agreement LES-LTM-21309)
> 
>  include/odp/api/event.h   | 9 ++---
>  include/odp/api/pool.h| 2 --
>  platform/linux-generic/include/odp/plat/event_types.h | 1 -
>  3 files changed, 2 insertions(+), 10 deletions(-)
> 
> diff --git a/include/odp/api/event.h b/include/odp/api/event.h
> index 50c031a..ce97bdc 100644
> --- a/include/odp/api/event.h
> +++ b/include/odp/api/event.h
> @@ -36,11 +36,6 @@ extern "C" {
>   */
> 
>  /**
> - * @def ODP_EVENT_TYPE_INVALID
> - * Invalid event type
> - */
> -
> -/**
>   * @def ODP_EVENT_BUFFER
>   * Buffer event
>   */
> @@ -61,11 +56,11 @@ extern "C" {
>   */
> 
>  /**
> - * Event type
> + * Return type of event

Don't change the Doxygen brief description. Almost every function return 
something, no need to mention that in the brief description. The detail 
description is there for full description/sentences.

Otherwise OK.

-Petri


>   *
>   * @param eventEvent handle
>   *
> - * @return Event type or ODP_EVENT_TYPE_INVALID
> + * @return Event type
>   */
>  int odp_event_type(odp_event_t event);
> 
> diff --git a/include/odp/api/pool.h b/include/odp/api/pool.h
> index 1582102..d09d92e 100644
> --- a/include/odp/api/pool.h
> +++ b/include/odp/api/pool.h
> @@ -79,8 +79,6 @@ typedef struct odp_pool_param_t {
> 
>  } odp_pool_param_t;
> 
> -/** Invalid pool type */
> -#define ODP_POOL_TYPE_INVALID ODP_EVENT_TYPE_INVALID
>  /** Packet pool*/
>  #define ODP_POOL_PACKET   ODP_EVENT_PACKET
>  /** Buffer pool */
> diff --git a/platform/linux-generic/include/odp/plat/event_types.h
> b/platform/linux-generic/include/odp/plat/event_types.h
> index 4a0756b..c98d416 100644
> --- a/platform/linux-generic/include/odp/plat/event_types.h
> +++ b/platform/linux-generic/include/odp/plat/event_types.h
> @@ -30,7 +30,6 @@ typedef odp_buffer_t odp_event_t;
> 
>  #define ODP_EVENT_INVALID ODP_BUFFER_INVALID
> 
> -#define ODP_EVENT_TYPE_INVALID (-1)
>  #define ODP_EVENT_BUFFER 1
>  #define ODP_EVENT_PACKET 2
>  #define ODP_EVENT_TIMEOUT3
> --
> 1.9.1
> 
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp

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

Re: [lng-odp] [PATCH 1/5] api: odp_hints: Add ODP_NORETURN

[Savolainen, Petri (NSN - FI/Espoo)]

Entire patch set:

Reviewed-by: Petri Savolainen 

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Mike Holmes
> Sent: Friday, January 30, 2015 12:52 AM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCH 1/5] api: odp_hints: Add ODP_NORETURN
> 
> Add the ability to mark a function as never returning to the caller.
> 
> Signed-off-by: Mike Holmes 
> ---
>  include/odp/api/hints.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/include/odp/api/hints.h b/include/odp/api/hints.h
> index 7f04886..a7aa90e 100644
> --- a/include/odp/api/hints.h
> +++ b/include/odp/api/hints.h
> @@ -25,6 +25,10 @@ extern "C" {
> 
>  #ifdef __GNUC__
> 
> +/** Define a fn that does not return
> + */
> +#define ODP_NORETURN __attribute__((__noreturn__))
> +
>  /** Define a weak symbol
>   * This is primarily useful in defining library functions that can be
>   * overridden in user code.
> --
> 2.1.0
> 
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp

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

Re: [lng-odp] [PATCH v1] api: classification: pmr statistics counter API moved out of ODP 1.0

[Savolainen, Petri (NSN - FI/Espoo)]

Reviewed-by: Petri Savolainen 

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext bala.manoha...@linaro.org
> Sent: Friday, January 30, 2015 8:20 AM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCH v1] api: classification: pmr statistics counter
> API moved out of ODP 1.0
> 
> From: Balasubramanian Manoharan 
> 
> odp_pmr_match_count() API related to statistics count of PMR has been
> moved out of ODP 1.0
> version and the same will be incorporated once an ODP level common
> statistics counter design has
> been achieved.
> 
> Signed-off-by: Balasubramanian Manoharan 
> ---
>  include/odp/api/classification.h|  9 -
>  platform/linux-generic/odp_classification.c |  8 
>  .../classification/odp_classification_tests.c   | 21 
> -
>  3 files changed, 38 deletions(-)
> 
> diff --git a/include/odp/api/classification.h
> b/include/odp/api/classification.h
> index 5c6636f..609d529 100644
> --- a/include/odp/api/classification.h
> +++ b/include/odp/api/classification.h
> @@ -279,15 +279,6 @@ int odp_pktio_pmr_cos(odp_pmr_t pmr_id,
>  int odp_cos_pmr_cos(odp_pmr_t pmr_id, odp_cos_t src_cos, odp_cos_t
> dst_cos);
> 
>  /**
> - * Retrieve packet matcher statistics
> - *
> - * @param[in]pmr_id  PMR from which to retrieve the count
> - *
> - * @return   Current number of matches for a given matcher
> instance.
> - */
> -signed long odp_pmr_match_count(odp_pmr_t pmr_id);
> -
> -/**
>   * Inquire about matching terms supported by the classifier
>   *
>   * @return A mask one bit per enumerated term, one for each of
> op_pmr_term_e
> diff --git a/platform/linux-generic/odp_classification.c b/platform/linux-
> generic/odp_classification.c
> index 78597ef..31d1328 100644
> --- a/platform/linux-generic/odp_classification.c
> +++ b/platform/linux-generic/odp_classification.c
> @@ -505,14 +505,6 @@ int odp_cos_pmr_cos(odp_pmr_t pmr_id, odp_cos_t
> src_cos, odp_cos_t dst_cos)
>   return 0;
>  }
> 
> -signed long odp_pmr_match_count(odp_pmr_t pmr_id)
> -{
> - pmr_t *pmr = get_pmr_entry(pmr_id);
> - if (pmr == NULL)
> - return -1;
> - return (signed long)odp_atomic_load_u32(&pmr->s.count);
> -}
> -
>  unsigned long long odp_pmr_terms_cap(void)
>  {
>   unsigned long long term_cap = 0;
> diff --git a/test/validation/classification/odp_classification_tests.c
> b/test/validation/classification/odp_classification_tests.c
> index e4b3260..45822d3 100644
> --- a/test/validation/classification/odp_classification_tests.c
> +++ b/test/validation/classification/odp_classification_tests.c
> @@ -423,8 +423,6 @@ void test_cls_pmr_chain(void)
>   pkt = receive_packet(&queue, ODP_TIME_SEC);
>   CU_ASSERT(queue == queue_list[CLS_PMR_CHAIN_SRC]);
>   CU_ASSERT(seq == cls_pkt_get_seq(pkt));
> -
> - CU_ASSERT(1 == odp_pmr_match_count(pmr_list[CLS_PMR_CHAIN_DST]));
>   odp_packet_free(pkt);
>  }
> 
> @@ -657,7 +655,6 @@ void test_pmr_cos(void)
>   pkt = receive_packet(&queue, ODP_TIME_SEC);
>   CU_ASSERT(queue == queue_list[CLS_PMR]);
>   CU_ASSERT(seq == cls_pkt_get_seq(pkt));
> - CU_ASSERT(1 == odp_pmr_match_count(pmr_list[CLS_PMR]));
>   odp_packet_free(pkt);
>  }
> 
> @@ -740,23 +737,6 @@ void test_pktio_pmr_match_set_cos(void)
>   odp_packet_free(pkt);
>  }
> 
> -static void classification_pmr_match_count(void)
> -{
> - odp_pmr_t pmr;
> - uint16_t val;
> - uint16_t mask;
> - val = 1024;
> - mask = 0x;
> - int retval;
> - pmr = odp_pmr_create_match(ODP_PMR_TCP_SPORT, &val, &mask,
> sizeof(val));
> - CU_ASSERT(pmr != ODP_PMR_INVAL);
> -
> - retval = odp_pmr_match_count(pmr);
> - CU_ASSERT(retval == 0);
> -
> - odp_pmr_destroy(pmr);
> -}
> -
>  static void classification_pmr_terms_avail(void)
>  {
>   int retval;
> @@ -814,6 +794,5 @@ CU_TestInfo classification_tests[] = {
>   _CU_TEST_INFO(classification_pmr_terms_cap),
>   _CU_TEST_INFO(classification_pktio_configure),
>   _CU_TEST_INFO(classification_pktio_test),
> - _CU_TEST_INFO(classification_pmr_match_count),
>   CU_TEST_INFO_NULL,
>  };
> --
> 2.0.1.472.g6f92e5f
> 
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp

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

Re: [lng-odp] [PATCH 1/2] api: pool: Added packet pool parameters

[Savolainen, Petri (NSN - FI/Espoo)]

Hi,

An ODP application is SW running on cores (not HW or firmware). If there's no 
SW, there's no need for ODP API. Application receives odp_packets, which 
consist of odp_packet_segs. From application point of view, each segment is a 
block of contiguous memory (implementation can be anything as long as 
application can access it contiguously). Application has the knowledge on 
incoming packets and SW processing of those. Segmentation is a trade-off 
between linear memory processing (good performance) and memory usage. These 
parameters give application the change to tune the trade-off in each use case.

For example, application may
- receive 49% 64 byte packets, 49% 1500 byte packets and 2% 9kB packets
- read up to 300 bytes into a packet 
- add upto 54 bytes of tunnel headers in front of the packet
=> ask first min seg len 354 bytes, that would fit all accesses. Implementation 
rounds that up to 384 bytes (full cache line)
=> run tests and notice that performance is good, but we need to lower the 
memory usage of this pool
=> drop min seg len to 200 bytes, implementation rounds that to 256
=> run tests, performance is still good enough and pool uses less memory (which 
can be then  used for something else)

How implementation could do this trade-off analysis behalf of the user? 


+   uint32_t seg_len;   /**< Minimum packet segment buffer
+length in bytes. It includes
+possible head-/tailroom bytes.
+Use 0 for default length. */

In addition to this, we have lower and upper config limits 
(ODP_CONFIG_PACKET_BUF_LEN_XXX need to be updated also). If implementation can 
support only one segment len, it will be documented by those min/max limits 
being the same.


-Petri



> -Original Message-
> From: ext Ola Liljedahl [mailto:ola.liljed...@linaro.org]
> Sent: Sunday, February 01, 2015 12:06 AM
> To: Bill Fischofer
> Cc: Petri Savolainen; LNG ODP Mailman List
> Subject: Re: [lng-odp] [PATCH 1/2] api: pool: Added packet pool parameters
> 
> One important aspect of ODP is a hardware abstraction, the ODP API is
> supposed to hide implementations details such as how buffers are
> managed (segmentation is one implementation detail that we allow to
> leak through as this is common and very expensive to hide from the
> application). I recently heard of a 40G NIC which doesn't use (user
> visible) buffer pools at all. You just pass a large (shared) memory
> region to the NIC and it carves up suitable buffers as needed.
> Needless to say, DPDK has problem with that. But ODP shouldn't.
> 
> On 31 January 2015 at 01:22, Bill Fischofer 
> wrote:
> > I really can't concur with this proposed design.  The fundamental issue
> here
> > is the proper relationship between applications and implementations with
> > respect to packet storage.  Packets have an overall length, and this is
> > within the purview of the application, since it understands the type of
> > traffic it is looking to process.  Length is a property that packets
> have
> > "on the wire" and is independent of how packets may be stored within a
> > processing node.
> >
> > Segments are always an implementation construct and exist for the
> > convenience of an implementation. Segments do not exist on the wire and
> are
> > not part of any inherent (i.e., platform-independent) packet structure.
> To
> > assert application control over packet segmentation is to say that the
> > application is controlling the implementation of packet storage. This is
> a
> > fundamental departure from the API/Implementation separation paradigm
> that
> > ODP is promoting.   If an application wishes to do this it is leaving no
> > room for HW offload or innovation in this area--it's just using the HW
> as a
> > raw block manager and doing everything itself in SW.
> >
> > It is understood that the existence of segmentation imposes some
> processing
> > overhead on SW to the extent that SW must deal with the "seams" in a
> packet
> > addressability that results from segmentation.  There are two ways to
> > address this.
> >
> > The first is to recognize that in the data plane the vast bulk of
> processing
> > is on packet headers rather than payload and that HW is aware of this
> fact,
> > which is why HW designed for packet processing invariably uses segment
> sizes
> > large enough to contain all of the packet headers within the first
> packet
> > segment for the vast majority of packets of interest. In the spec we
> worked
> > on last year we stated that ODP would require a minimum segment size of
> 256
> > bytes so that applications would have assurance regarding this, and no
> > surveyed platforms had issues with that.
> >
> > The second means of addressing this problem is to allow applications to
> > explicitly request unsegmented pools.  While recognizing that not all
> > platforms can provide unsegmented 

Re: [lng-odp] [PATCH 1/2] api: config: move ODP_SHM_NUM_BLOCKS to config.h

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Mike Holmes
> Sent: Saturday, January 31, 2015 3:21 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCH 1/2] api: config: move ODP_SHM_NUM_BLOCKS to
> config.h
> 
> ODP_SHM_NUM_BLOCKS was defined down in the implementation, move it out
> to the config.h
> 
> Signed-off-by: Mike Holmes 
> ---
>  include/odp/api/config.h   | 6 ++
>  platform/linux-generic/odp_shared_memory.c | 5 +
>  2 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/include/odp/api/config.h b/include/odp/api/config.h
> index 3529fca..16157b0 100644
> --- a/include/odp/api/config.h
> +++ b/include/odp/api/config.h
> @@ -119,6 +119,12 @@ extern "C" {
>   */
>  #define ODP_CONFIG_PACKET_BUF_LEN_MAX (ODP_CONFIG_PACKET_BUF_LEN_MIN*6)
> 
> +/** Maximum number of shared memory blocks.
> + *
> + * Limits how many blocks are available for calls to odp_shm_reserve()
> + */
> +#define ODP_SHM_NUM_BLOCKS 32


All config macros must have ODP_CONFIG_ prefix. So rename it to this:

#define ODP_CONFIG_SHM_BLOCKS 64


-Petri


> +
>  /**
>   * @}
>   */
> diff --git a/platform/linux-generic/odp_shared_memory.c b/platform/linux-
> generic/odp_shared_memory.c
> index 96d10e8..e157871 100644
> --- a/platform/linux-generic/odp_shared_memory.c
> +++ b/platform/linux-generic/odp_shared_memory.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include 
>  #include 
> @@ -26,10 +27,6 @@
>  #include 
>  #include 
> 
> -
> -#define ODP_SHM_NUM_BLOCKS 32
> -
> -
>  typedef struct {
>   char  name[ODP_SHM_NAME_LEN];
>   uint64_t  size;
> --
> 2.1.0
> 
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp

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

Re: [lng-odp] Handling xxx_INVALID handles

[Savolainen, Petri (NSN - FI/Espoo)]

> 
> I don't think these use cases can be supported unless we define that
> ODP calls must detect INVALID handles and handle them in a
> well-defined manner. The question is which calls, perhaps all of them.

To me "undefined behavior" is crash or return error. That should be the goal 
for implementers anyway.

Implementation has basically two options
- use pointer as handle and access that without checking it => crash
- use index as handle: fast to check it and return error, or map the table 
memory so that invalid handle cause page miss and crash.

Third, option would be to successfully use invalid handles/pointers into memory 
and return success for any random handles, but I would not use that 
implementation for production...

-Petri

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

Re: [lng-odp] Handling xxx_INVALID handles

[Savolainen, Petri (NSN - FI/Espoo)]

> >> > x = odp_xxx_create(...);  // error! => Returns XXX_INVALID
> >> > y = odp_yyy_create(x, );  // x == XXX_INVALID => error!
> When in ODP will this be the recommended or desired practice? Either
> the user will have to check the return values for success or the
> different calls will have to check their inputs for validity.
> 
> If we are trying to support a number of (non-obvious) design patterns
> for the applications to use, these need to be documented (e.g. in
> architecture document or user's guide).

There only one design pattern for application: check return values. We provide 
error check possibility for implementation.

> >
> > x = XXX_INVALID; //init
> Why initialize x at all? The compiler will warn you if you are reading
> x before it has been assigned a value. IMO default initializations are
> dangerous.

It documents your intention: by default I'm doing X.

Yes, compiler can check that it's always set, but it does not which values 
produce correct behavior by default (e.g. fail/crash by default).

-Petri


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

Re: [lng-odp] Handling xxx_INVALID handles

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: ext Taras Kondratiuk [mailto:taras.kondrat...@linaro.org]
> Sent: Friday, January 30, 2015 3:17 PM
> To: Savolainen, Petri (NSN - FI/Espoo)
> Cc: ext Ola Liljedahl; lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] Handling xxx_INVALID handles
> 
> On 01/30/2015 02:41 PM, Savolainen, Petri (NSN - FI/Espoo) wrote:
> >
> >
> >> -Original Message-
> >> From: ext Taras Kondratiuk [mailto:taras.kondrat...@linaro.org]
> >> Sent: Friday, January 30, 2015 2:28 PM
> >> To: Savolainen, Petri (NSN - FI/Espoo); ext Ola Liljedahl
> >> Cc: lng-odp@lists.linaro.org
> >> Subject: Re: [lng-odp] Handling xxx_INVALID handles
> >>
> >> On 01/30/2015 02:06 PM, Savolainen, Petri (NSN - FI/Espoo) wrote:
> >>>
> >>>
> >>>> -Original Message-
> >>>> From: ext Taras Kondratiuk [mailto:taras.kondrat...@linaro.org]
> >>>> Sent: Friday, January 30, 2015 1:50 PM
> >>>> To: Savolainen, Petri (NSN - FI/Espoo); ext Ola Liljedahl
> >>>> Cc: lng-odp@lists.linaro.org
> >>>> Subject: Re: [lng-odp] Handling xxx_INVALID handles
> >>>>
> >>>> On 01/30/2015 01:15 PM, Savolainen, Petri (NSN - FI/Espoo) wrote:
> >>>>> As explained below, XXX_NULL != XXX_INVALID enables to distinguish
> >> this
> >>>> error ...
> >>>>>
> >>>>> x = odp_xxx_create(...);  // error! => Returns XXX_INVALID
> >>>>> y = odp_yyy_create(x, );  // x == XXX_INVALID => error!
> >>>>
> >>>> Deferring error detection to a second function doesn't look like a
> good
> >>>> practice. It will be harder to determine a cause of the error then.
> >>>
> >>> The "error!" mains any, undefined error (e.g. crash). It's an example
> of
> >> an error, another would be this.
> >>>
> >>> x = XXX_INVALID; //init
> >>>
> >>> // forgot to set x with valid value
> >>>
> >>> y = odp_yyy_create(x, );  // x == XXX_INVALID => error!
> >>>
> >>>
> >>>>
> >>>> Also 'x == XXX_INVALID => error!' is not a correct statement.
> >>>> We agreed that 'x == XXX_INVALID => *undefined behavior*', so this is
> a
> >>>> definitely a bad example.
> >>>
> >>> Error! == undefined error, crash!
> >>
> >> 'Undefined behavior' means not only error return or crash, but it can
> >> silently succeed and mess some unrelated stuff. So application will
> >> crash later in some random place. Do you want to promote such API
> usage?
> >>
> >> Sorry, but I'm really missing your point.
> >
> >
> > The point is that, if we use XXX_INVALID to indicate that user choose to
> let the implementation decide on parameter X (e.g. let pool_create() to
> reserve the shared memory), how implementation would separate that
> intention from a bad handle (like XXX_INVALID)?
> >
> > We reserve special handle id XXX_NULL for that purpose only. When user
> gives that implementation, do not crash etc, but knows that it has to
> reserve the resource X.
> >
> > Behaviour is undefined:
> > odp_xxx_create(XXX_INVALID, ..)
> >
> > Behaviour is defined:
> > odp_xxx_create(XXX_NULL, ..)
> 
> I understand that part, but if I try to list possible use cases which
> don't cause undefined behavior, then XXX_INVALID seems to be redundant
> anyway.
> 
> Let's take your example
> 
> >>>>> x = odp_xxx_create(...);  // error! => Returns XXX_INVALID
> >>>>> y = odp_yyy_create(x, );  // x == XXX_INVALID => error!
> 
> - If x can be XXX_INVALID, then application have to *always* check it
>before passing to odp_yyy_create(). Otherwise - undefined behavior.
> - If application have to check it anyway, then it can test it against
>ODP_XXX_NULL -> odp_xxx_create() can return _NULL instead of _INVALID.
> - If x is ODP_XXX_NULL, then odp_yyy_create() should not be called.
> - No need for ODP_XXX_INVALID.
> 
> Can you give an example which doesn't cause undefined behavior where
> both XXX_IVALID and XXX_NULL are needed?

The example above is an example of bad application. Of course application 
should check x before passing it forward, but when it _fails_ to do so (or 
inits it but fails to set it with a valid handle), we are still possible to 
catch that.

If we use the 

Re: [lng-odp] Handling xxx_INVALID handles

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: ext Taras Kondratiuk [mailto:taras.kondrat...@linaro.org]
> Sent: Friday, January 30, 2015 2:28 PM
> To: Savolainen, Petri (NSN - FI/Espoo); ext Ola Liljedahl
> Cc: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] Handling xxx_INVALID handles
> 
> On 01/30/2015 02:06 PM, Savolainen, Petri (NSN - FI/Espoo) wrote:
> >
> >
> >> -Original Message-
> >> From: ext Taras Kondratiuk [mailto:taras.kondrat...@linaro.org]
> >> Sent: Friday, January 30, 2015 1:50 PM
> >> To: Savolainen, Petri (NSN - FI/Espoo); ext Ola Liljedahl
> >> Cc: lng-odp@lists.linaro.org
> >> Subject: Re: [lng-odp] Handling xxx_INVALID handles
> >>
> >> On 01/30/2015 01:15 PM, Savolainen, Petri (NSN - FI/Espoo) wrote:
> >>> As explained below, XXX_NULL != XXX_INVALID enables to distinguish
> this
> >> error ...
> >>>
> >>> x = odp_xxx_create(...);  // error! => Returns XXX_INVALID
> >>> y = odp_yyy_create(x, );  // x == XXX_INVALID => error!
> >>
> >> Deferring error detection to a second function doesn't look like a good
> >> practice. It will be harder to determine a cause of the error then.
> >
> > The "error!" mains any, undefined error (e.g. crash). It's an example of
> an error, another would be this.
> >
> > x = XXX_INVALID; //init
> >
> > // forgot to set x with valid value
> >
> > y = odp_yyy_create(x, );  // x == XXX_INVALID => error!
> >
> >
> >>
> >> Also 'x == XXX_INVALID => error!' is not a correct statement.
> >> We agreed that 'x == XXX_INVALID => *undefined behavior*', so this is a
> >> definitely a bad example.
> >
> > Error! == undefined error, crash!
> 
> 'Undefined behavior' means not only error return or crash, but it can
> silently succeed and mess some unrelated stuff. So application will
> crash later in some random place. Do you want to promote such API usage?
> 
> Sorry, but I'm really missing your point.


The point is that, if we use XXX_INVALID to indicate that user choose to let 
the implementation decide on parameter X (e.g. let pool_create() to reserve the 
shared memory), how implementation would separate that intention from a bad 
handle (like XXX_INVALID)?

We reserve special handle id XXX_NULL for that purpose only. When user gives 
that implementation, do not crash etc, but knows that it has to reserve the 
resource X.

Behaviour is undefined: 
odp_xxx_create(XXX_INVALID, ..)

Behaviour is defined: 
odp_xxx_create(XXX_NULL, ..)


-Petri








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

Re: [lng-odp] Handling xxx_INVALID handles

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: ext Taras Kondratiuk [mailto:taras.kondrat...@linaro.org]
> Sent: Friday, January 30, 2015 1:50 PM
> To: Savolainen, Petri (NSN - FI/Espoo); ext Ola Liljedahl
> Cc: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] Handling xxx_INVALID handles
> 
> On 01/30/2015 01:15 PM, Savolainen, Petri (NSN - FI/Espoo) wrote:
> > As explained below, XXX_NULL != XXX_INVALID enables to distinguish this
> error ...
> >
> > x = odp_xxx_create(...);  // error! => Returns XXX_INVALID
> > y = odp_yyy_create(x, );  // x == XXX_INVALID => error!
> 
> Deferring error detection to a second function doesn't look like a good
> practice. It will be harder to determine a cause of the error then.

The "error!" mains any, undefined error (e.g. crash). It's an example of an 
error, another would be this.

x = XXX_INVALID; //init

// forgot to set x with valid value

y = odp_yyy_create(x, );  // x == XXX_INVALID => error!

 
> 
> Also 'x == XXX_INVALID => error!' is not a correct statement.
> We agreed that 'x == XXX_INVALID => *undefined behavior*', so this is a
> definitely a bad example.

Error! == undefined error, crash!

-Petri

> 
> >
> >
> > ... from this valid use case (user choose to leave x NULL)
> >
> > y = odp_yyy_create(XXX_NULL, );
> 
> 
> 
> >
> >
> >
> > -Petri
> >
> >
> >> -Original Message-
> >> From: ext Ola Liljedahl [mailto:ola.liljed...@linaro.org]
> >> Sent: Friday, January 30, 2015 10:58 AM
> >> To: Savolainen, Petri (NSN - FI/Espoo)
> >> Cc: ext Bill Fischofer; lng-odp@lists.linaro.org
> >> Subject: Re: [lng-odp] Handling xxx_INVALID handles
> >>
> >> On 30 January 2015 at 09:08, Savolainen, Petri (NSN - FI/Espoo)
> >>  wrote:
> >>>
> >>>
> >>> In API definition, XXX_NULL is not alias for XXX_INVALID. When user
> >> passes
> >>> XXX_NULL, it tells that application did not pass a handle. If user
> >> passes
> >>> XXX_INVALID, it’s an error (e.g. another ODP call returned XXX_INVALID
> >>> before this one, and user tries to pass that INVALID forward).
> >> How is this not like passing a NULL handle?
> >>>
> >>>
> >>>
> >>> Current linux-generic odp_pool_create() implementation uses SHM_NULL
> and
> >>> SHM_INVALID as synonyms, but that’s not robust and actually against
> API
> >>> definition, since SHM_INVALID should cause an error.
> >> I understand the definition and usage of ODP_SHM_NULL, it's like any
> >> other NULL definitions, including the NULL pointer in C/C++.
> >>
> >> But if the INVALID and NULL handles are not supposed to be equivalent,
> >> then I don't understand why ODP needs the INVALID handles. You never
> >> need to specify an INVALID handle (if you have the NULL handle) and
> >> calls that cannot return a handle that refers to a valid object can
> >> return the NULL handle. So what's the INVALID handle for?
> >>
> >> Currently it seems like the INVALID handle is a synonym for the NULL
> >> handle but only for outputs (return values) according to your
> >> statement above.
> >>
> >> The semantics of the different ODP operations here do not seem
> >> different from e.g. malloc, strdup and free. How come C can support
> >> these operations with only a NULL handle?
> >>
> >>>
> >>>
> >>>
> >>> -Petri
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> From: lng-odp-boun...@lists.linaro.org
> >>> [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of ext Bill
> >> Fischofer
> >>> Sent: Thursday, January 29, 2015 11:14 PM
> >>> To: Ola Liljedahl
> >>> Cc: lng-odp@lists.linaro.org
> >>> Subject: Re: [lng-odp] Handling xxx_INVALID handles
> >>>
> >>>
> >>>
> >>> Given that pool creation/deletion is a relatively involved procedure
> and
> >> not
> >>> expected to be called frequently, it makes sense to include full
> >> parameter
> >>> validation as part of the operation.  The same should be true for
> other
> >> APIs
> >>> with similar expected call frequencies.
> >>>
> >>>
> >>>
> >>> We do allow explicit INVALID input parameters, however for semantic
> >> reasons
> >>> they sometimes have aliases.  For example, odp_pool_create() can take
> >>> ODP_SHM_NULL as input to specify that the caller is not supplying a
> shm
> >>> handle.  However this is just an alias for ODP_SHM_INVALID since that
> is
> >> the
> >>> distinguished "not a handle" value for that data type.
> >>>
> >>>
> > ___
> > lng-odp mailing list
> > lng-odp@lists.linaro.org
> > http://lists.linaro.org/mailman/listinfo/lng-odp
> >

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

Re: [lng-odp] Handling xxx_INVALID handles

[Savolainen, Petri (NSN - FI/Espoo)]

As explained below, XXX_NULL != XXX_INVALID enables to distinguish this error 
...

x = odp_xxx_create(...);  // error! => Returns XXX_INVALID
y = odp_yyy_create(x, );  // x == XXX_INVALID => error!


... from this valid use case (user choose to leave x NULL)

y = odp_yyy_create(XXX_NULL, );



-Petri


> -Original Message-
> From: ext Ola Liljedahl [mailto:ola.liljed...@linaro.org]
> Sent: Friday, January 30, 2015 10:58 AM
> To: Savolainen, Petri (NSN - FI/Espoo)
> Cc: ext Bill Fischofer; lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] Handling xxx_INVALID handles
> 
> On 30 January 2015 at 09:08, Savolainen, Petri (NSN - FI/Espoo)
>  wrote:
> >
> >
> > In API definition, XXX_NULL is not alias for XXX_INVALID. When user
> passes
> > XXX_NULL, it tells that application did not pass a handle. If user
> passes
> > XXX_INVALID, it’s an error (e.g. another ODP call returned XXX_INVALID
> > before this one, and user tries to pass that INVALID forward).
> How is this not like passing a NULL handle?
> >
> >
> >
> > Current linux-generic odp_pool_create() implementation uses SHM_NULL and
> > SHM_INVALID as synonyms, but that’s not robust and actually against API
> > definition, since SHM_INVALID should cause an error.
> I understand the definition and usage of ODP_SHM_NULL, it's like any
> other NULL definitions, including the NULL pointer in C/C++.
> 
> But if the INVALID and NULL handles are not supposed to be equivalent,
> then I don't understand why ODP needs the INVALID handles. You never
> need to specify an INVALID handle (if you have the NULL handle) and
> calls that cannot return a handle that refers to a valid object can
> return the NULL handle. So what's the INVALID handle for?
> 
> Currently it seems like the INVALID handle is a synonym for the NULL
> handle but only for outputs (return values) according to your
> statement above.
> 
> The semantics of the different ODP operations here do not seem
> different from e.g. malloc, strdup and free. How come C can support
> these operations with only a NULL handle?
> 
> >
> >
> >
> > -Petri
> >
> >
> >
> >
> >
> > From: lng-odp-boun...@lists.linaro.org
> > [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of ext Bill
> Fischofer
> > Sent: Thursday, January 29, 2015 11:14 PM
> > To: Ola Liljedahl
> > Cc: lng-odp@lists.linaro.org
> > Subject: Re: [lng-odp] Handling xxx_INVALID handles
> >
> >
> >
> > Given that pool creation/deletion is a relatively involved procedure and
> not
> > expected to be called frequently, it makes sense to include full
> parameter
> > validation as part of the operation.  The same should be true for other
> APIs
> > with similar expected call frequencies.
> >
> >
> >
> > We do allow explicit INVALID input parameters, however for semantic
> reasons
> > they sometimes have aliases.  For example, odp_pool_create() can take
> > ODP_SHM_NULL as input to specify that the caller is not supplying a shm
> > handle.  However this is just an alias for ODP_SHM_INVALID since that is
> the
> > distinguished "not a handle" value for that data type.
> >
> >
___
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] Handling xxx_INVALID handles

[Savolainen, Petri (NSN - FI/Espoo)]

In API definition, XXX_NULL is not alias for XXX_INVALID. When user passes 
XXX_NULL, it tells that application did not pass a handle. If user passes 
XXX_INVALID, it’s an error (e.g. another ODP call returned XXX_INVALID before 
this one, and user tries to pass that INVALID forward).

Current linux-generic odp_pool_create() implementation uses SHM_NULL and 
SHM_INVALID as synonyms, but that’s not robust and actually against API 
definition, since SHM_INVALID should cause an error.

-Petri


From: lng-odp-boun...@lists.linaro.org 
[mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of ext Bill Fischofer
Sent: Thursday, January 29, 2015 11:14 PM
To: Ola Liljedahl
Cc: lng-odp@lists.linaro.org
Subject: Re: [lng-odp] Handling xxx_INVALID handles

Given that pool creation/deletion is a relatively involved procedure and not 
expected to be called frequently, it makes sense to include full parameter 
validation as part of the operation.  The same should be true for other APIs 
with similar expected call frequencies.

We do allow explicit INVALID input parameters, however for semantic reasons 
they sometimes have aliases.  For example, odp_pool_create() can take 
ODP_SHM_NULL as input to specify that the caller is not supplying a shm handle. 
 However this is just an alias for ODP_SHM_INVALID since that is the 
distinguished "not a handle" value for that data type.

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

Re: [lng-odp] Handling xxx_INVALID handles

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
> Sent: Thursday, January 29, 2015 7:02 PM
> To: Taras Kondratiuk
> Cc: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] Handling xxx_INVALID handles
> 
> On 29 January 2015 at 17:46, Taras Kondratiuk
>  wrote:
> 
> Petri requires calls on shared resources (e.g. shared memory, pools)
> to be robust even when called with *stale* handles (because some other
> thread might just have freed the shared resource).

No, implementation is _not required_ to do that check, but API definition must 
not ban that check. If implementation can check it, it can return an error. If 
it cannot check, it will crash. Application will always check the return value.

-Petri
 


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

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

Re: [lng-odp] Handling xxx_INVALID handles

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Taras Kondratiuk
> Sent: Thursday, January 29, 2015 6:47 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] Handling xxx_INVALID handles
> 
> Hi
> 
> We had a discussion recently about wrong ODP handles passed to API
> functions. As far as I remember we agreed that in this case behavior is
> undefined. What about passing xxx_INVALID values to API?
> 
> Currently packet IO verification tests pass ODP_PKTIO_INVALID explicitly
> to some API functions and expect them to return error.
> 

Generally, XXX_INVALID is as bad handle as any other random value, and API 
calls are not expected handle it differently (if not documented otherwise). 
It's implementation choice if it checks for that specific value (and on which 
debug levels).

XXX_NULL handle is specific (input) value telling that user does not give a 
valid handle and e.g. lets the implementation to allocate the resource.

-Petri


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

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

Re: [lng-odp] [PATCHv4 0/5] api: crypto: ODP 1.0 API update

[Savolainen, Petri (NSN - FI/Espoo)]

Did that already here: 
Re: [lng-odp] [PATCHv4 1/5] api: crypto: new completion event scheme

.. with two things to be done after merge. It's OK to merge.


-Petri



> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Maxim Uvarov
> Sent: Thursday, January 29, 2015 4:19 PM
> To: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [PATCHv4 0/5] api: crypto: ODP 1.0 API update
> 
> Petri, do you want to write your sign-off here?
> 
> Maxim.
> 
> On 01/28/2015 08:42 PM, Robbie King wrote:
> > v1 - Move completion event allocation into implementation,
> >   allow synchronous implementation to return status
> >   immediately (i.e. no completion event involved).
> >   Fix two crypto related issues found during debug.
> >
> > v2 - Merged with odp_event_t changes.
> >
> > v3 - Changed bool to odp_bool_t throughout crypto API,
> >   examples and tests.
> >
> > v4 - Incorporate Petri's naming comments and fully implement
> >   events within crypto.  Modified the IPSec example to
> >   use event type for steering dequeued work.
> >
> > Robbie King (5):
> >api: crypto: new completion event scheme
> >api: packet: add API to copy metadata
> >example: ipsec: move L2/3/4 offset set
> >api: crypto: change bool to odp_bool_t
> >example: ipsec: use event type at dequeue
> >
> >   example/ipsec/odp_ipsec.c  | 100 ++---
> -
> >   example/ipsec/odp_ipsec_cache.c|   2 +-
> >   example/ipsec/odp_ipsec_cache.h|   4 +-
> >   example/ipsec/odp_ipsec_misc.h |   4 +-
> >   example/ipsec/odp_ipsec_sa_db.c|   4 +-
> >   example/ipsec/odp_ipsec_sa_db.h|   4 +-
> >   example/ipsec/odp_ipsec_sp_db.h|   6 +-
> >   example/ipsec/odp_ipsec_stream.c   |  20 ++--
> >   example/ipsec/odp_ipsec_stream.h   |   6 +-
> >   platform/linux-generic/include/api/odp_crypto.h| 108 ++---
> --
> >   platform/linux-generic/include/api/odp_event.h |   2 +
> >   .../linux-generic/include/odp_buffer_internal.h|   8 ++
> >   .../linux-generic/include/odp_crypto_internal.h|   8 +-
> >   .../linux-generic/include/odp_packet_internal.h|   2 +
> >   platform/linux-generic/odp_buffer.c|   7 ++
> >   platform/linux-generic/odp_crypto.c| 116 ++---
> 
> >   platform/linux-generic/odp_packet.c|  14 +++
> >   test/validation/crypto/odp_crypto_test_async_inp.c |  97 -
> 
> >   test/validation/crypto/odp_crypto_test_sync_inp.c  |  16 ++-
> >   19 files changed, 264 insertions(+), 264 deletions(-)
> >
> 
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp

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

Re: [lng-odp] API questions - sizes and numelems as inputs and outputs

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
> Sent: Wednesday, January 28, 2015 7:06 PM
> To: LNG ODP Mailman List
> Subject: [lng-odp] API questions - sizes and numelems as inputs and
> outputs
> 
> Talking about API's that take some type of element count or buffer
> size as input and return a value related to that. There seems to be a
> number of different models.
> 
> /**
>  * Generate random byte string
>  *
>  * @param buf  Pointer to store result
>  * @param len  Pointer to input length value as well as return
> value
> I assume the "return value" is the number of result bytes stored. But
> this is not very clear.
> 
>  * @param use_entropy  Use entropy
>  *
>  * @todo Define the implication of the use_entropy parameter
>  *
>  * @retval 0 on success
> Not the same "return value" as described above.
> 
>  * @retval <0 on failure
>  */
> int odp_hw_random_get(uint8_t *buf, size_t *len, bool use_entropy);
> Here we return the actual size written (I assume) through the len
> parameter which is consequently passed by reference.

How use full the function is if it does not fill the whole buffer with rand 
data? I think in this case should be success vs. failure. In success the whole 
buffer is written. 

> 
> /**
>  * Write CPU mask as a string of hexadecimal digits
>  *
>  * @param mask   CPU mask to write
>  * @param bufOutput buffer
>  * @param bufsz  Size of output buffer
>  *
>  * @return >0 on success. Number of characters written (including the
>  * terminating null char).
>  * @return 0 on failure (output buffer too small).
>  */
> size_t odp_cpumask_to_str(const odp_cpumask_t *mask, char *buf, size_t
> bufsz);
> The new definition of odp_cpumask_to_str() as recently agreed. Number
> of characters written is returned. It can't be 0 so 0 can be used as
> an error indicator. In other formatting-type of functions, 0 might be
> a valid return value (it primarily depends on whether the terminating
> null char should be included in the count).
> 
>   * @param[out] mac_addr  Storage for MAC address of the packet IO
> interface.
>   * @param  addr_size Storage size for the address
>   *
>  * @retval Number of bytes written on success, 0 on failure.
>   */
> size_t odp_pktio_mac_addr(odp_pktio_t id, void *mac_addr, size_t
> addr_size);
> This function returns 0 for failure (but this is incidental and
> prevents us to support pktio types that have zero-length MAC address
> (i.e. does not have any MAC address)).

What is a successful copy of a zero length MAC address? I think it's OK to 
return failure (==0), if user asks for a copy of MAC address from a interface 
that do not have one.

> 
> /**
>  * Copy data from packet
>  *
>  * Copy 'len' bytes of data from the packet level offset to the
> destination
>  * address.
>  *
>  * @param pktPacket handle
>  * @param offset Byte offset into the packet
>  * @param lenNumber of bytes to copy
>  * @param dstDestination address
>  *
>  * @retval 0 on success
>  * @retval <0 on failure
> Not documented what constitutes a failure.
> */
> int odp_packet_copydata_out(odp_packet_t pkt, uint32_t offset,
> uint32_t len, void *dst);
> What if less than len bytes could be copied (because reaching end of
> packet)? How is this reported? Should we use "uint32_t *len" and
> update it on return with the actual number of bytes copied? Or is this
> situation considered an error and reported with a negative return
> value? Seems excessive. Better to just specify len as the size of the
> output buffer and in some way be notified about the actual number of
> bytes copied.

It's better to keep this simple: success or failure. In success "len" bytes was 
copied. It's not important how many bytes were copied in failure. 

Failures:
offset > odp_packet_len()
offset + len > odp_packet_len()


> 
> /**
>  * Copy data into packet
>  *
>  * Copy'len' bytes of data from the source address into the packet
> level
>  * offset. Maximum number of bytes to copy is packet data length minus the
>  * offset. Packet is not modified on an error.
>  *
>  * @param pktPacket handle
>  * @param offset Byte offset into the packet
>  * @param lenNumber of bytes to copy
>  * @param srcSource address
>  *
>  * @retval 0 on success
>  * @retval <0 on failure
> Not documented what constitutes a failure.
>  */
> int odp_packet_copydata_in(odp_packet_t pkt, uint32_t offset,
>uint32_t len, const void *src);
> Similar for this function. Is it an error if 'len' bytes does not fit
> into the current packet size? Is this good semantics?

Failures:
offset > odp_packet_len()
offset + len > odp_packet_len()

> 
> /**
>  * Receive packets
>  *
>  * @param id  ODP packet IO handle
>  * @param pkt_table[] Storage for received packets (filled by function)
>  * @param len Length of pkt_table[], i.e. m

Re: [lng-odp] [PATCHv4 1/5] api: crypto: new completion event scheme

[Savolainen, Petri (NSN - FI/Espoo)]

Hi,

Reviewed-by: Petri Savolainen 

API changes are OK and can be merged today.


Two things should be fixed then on top of that.

1) odp_hw_random_get()

This could be renamed to e.g. odp_rand() and moved out from crypto header 
(odp_misc.h ?)

size_t odp_rand(uint8_t *buf, size_t len, odp_bool_t use_entropy);

Should it return number of bytes written, instead of output param *len?


2) 
Correct sequences to free a compl event needs to be specified more clearly. 
There seems to be only one right now?

compl = odp_crypto_compl_from_event(ev);

odp_crypto_compl_result(compl, &result);
odp_crypto_compl_free(compl);

if(result.pkt != ODP_PACKET_INVALID)
odp_packet_free(result.pkt)



Simple free call would result memory leak because the result packet would not 
be freed:

compl = odp_crypto_compl_from_event(ev);
odp_crypto_compl_free(compl);



> +
> +/**
> + * Release crypto completion event
> + *
> + * @param completion_event  Completion event we are done accessing

e.g.
@note User needs to free the potential result packet. This call frees the 
completion event only. 

> + */
> +void
> +odp_crypto_compl_free(odp_crypto_compl_t completion_event);




-Petri



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

Re: [lng-odp] odp_cpumask.h

[Savolainen, Petri (NSN - FI/Espoo)]

There's no warnings as long as size_t and ssize_t variables are not compared.


len = -odp_cpumask_to_str(&mask, NULL, 0);

This looks odd with the minus sign... Almost len -= ...


ssize_t odp_cpumask_to_str(const odp_cpumask_t *mask, char *buf, ssize_t bufsz);

This forces application to use signed buf length and implementation to check 
that bufsz >0.


size_t odp_cpumask_to_str(const odp_cpumask_t *mask, char *str, size_t len) 
would be closer to snprintf() types and logic... which people already know.


-Petri


> -Original Message-
> From: ext Ola Liljedahl [mailto:ola.liljed...@linaro.org]
> Sent: Wednesday, January 28, 2015 2:47 PM
> To: Savolainen, Petri (NSN - FI/Espoo)
> Cc: LNG ODP Mailman List
> Subject: Re: [lng-odp] odp_cpumask.h
> 
> The following code compiles without warnings or errors:
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> void test(odp_cpumask_t mask)
> {
> /* Start with a small value so that a retry will be forced */
> size_t len = 1;
> char *str;
> 
> for (;;) {
> ssize_t out;
> str = malloc(len);
> if (str == NULL)
> perror("malloc"), exit(EXIT_FAILURE);
> 
> out = odp_cpumask_to_str(&mask, str, len);
> if (out > 0) /* success */
> break;
> 
> /* failure, try with the recommended buffer size */
> free(str);
> len = -out;
> }
> /* do something with str */
> free(str);
> }
> 
> void test2(odp_cpumask_t mask)
> {
> char *str;
> size_t len;
> ssize_t out;
> /* Call with zero-length buffer, this will fail and return
> required
>  * buffer size */
> len = -odp_cpumask_to_str(&mask, NULL, 0);
> str = malloc(len);
> if (str == NULL)
> perror("malloc"), exit(EXIT_FAILURE);
> out = odp_cpumask_to_str(&mask, str, len);
> assert(out > 0);
> /* do something with str */
> free(str);
> }
> 
> ssize_t odp_cpumask_to_str(const odp_cpumask_t *mask, char *buf, ssize_t
> bufsz);
> 
> gcc -c -std=c99 -W -Wall -ansi -pedantic test.c -I
> platform/linux-generic/include/api/
> 
> Am I missing any important compiler flags this time?
> 
> 
> On 28 January 2015 at 13:32, Savolainen, Petri (NSN - FI/Espoo)
>  wrote:
> >> (maybe your audio was breaking on call yesterday on that part).
> >> I have tested mixing size_t and ssize_t and neither gcc nor clang
> >> complained. I was using -Wall -ansi -pedantic.
> >
> > Missing -W from there ? -Wall is not enough...
> >
> >
___
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] odp_cpumask.h

[Savolainen, Petri (NSN - FI/Espoo)]

> (maybe your audio was breaking on call yesterday on that part).
> I have tested mixing size_t and ssize_t and neither gcc nor clang
> complained. I was using -Wall -ansi -pedantic.

Missing -W from there ? -Wall is not enough...


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

Re: [lng-odp] odp_cpumask.h

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: ext Ola Liljedahl [mailto:ola.liljed...@linaro.org]
> Sent: Wednesday, January 28, 2015 2:03 PM
> To: Savolainen, Petri (NSN - FI/Espoo)
> Cc: LNG ODP Mailman List
> Subject: Re: [lng-odp] odp_cpumask.h
> 
> On 28 January 2015 at 12:55, Savolainen, Petri (NSN - FI/Espoo)
>  wrote:
> >
> >
> >> -Original Message-
> >> From: ext Ola Liljedahl [mailto:ola.liljed...@linaro.org]
> >> Sent: Wednesday, January 28, 2015 1:29 PM
> >> To: Savolainen, Petri (NSN - FI/Espoo)
> >> Cc: LNG ODP Mailman List
> >> Subject: Re: [lng-odp] odp_cpumask.h
> >>
> >> On 28 January 2015 at 12:21, Savolainen, Petri (NSN - FI/Espoo)
> >>  wrote:
> >> >
> >> >
> >> >> -Original Message-
> >> >> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> >> >> boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
> >> >> Sent: Wednesday, January 28, 2015 12:48 PM
> >> >> To: LNG ODP Mailman List
> >> >> Subject: [lng-odp] odp_cpumask.h
> >> >>
> >> >>  * @param strOutput buffer
> >> >>  * @param lenSize of string length (incl. ending zero)
> >> >>  */
> >> >> void odp_cpumask_to_str(const odp_cpumask_t *mask, char *str, int
> len);
> >> >>
> >> >> Why don't we use size_t for the"len" parameter?
> >> >>
> >> >> -- Ola
> >> >
> >> >
> >> > It's an object size, so it can be changed to size_t (similar to e.g.
> >> snprintf()).
> >> >
> >> > Packet data len/offsets, buffer sizes, packet/bytes counts etc,
> should
> >> be uintxx_t - but object sizes should be size_t.
> >> >
> >> >
> >> > Answer to: What happens if len < output length? Maybe we copy the
> >> snprintf definition (except output also ending zero). Return number
> chars
> >> written (incl. str ending zero), otherwise return number of chars that
> >> would have been outputted (return >len and clip output).
> >> This is more complicated to check for and goes against the convention
> >> of returning <0 for errors.
> >> I would prefer my suggestion with returning -(minimum required buffer
> >> size), there's a clear separation between success and error.
> >>
> >> And that we add a define with a suggested buffer size which will be
> >> usable when the CPU mask is full (all bits set), this seems to be 128
> >> when using Linux cpu_set_t for the implementation. Of course ODP could
> >> use a smaller max size as well.
> >
> >
> > About error from functions that return len. I'd have input param and
> return type the same, so that compiler don't complain when comparing those
> (maybe your audio was breaking on call yesterday on that part).
> No I didn't hear, my wifi router stopped working and had to be reset...
> 
> >
> > e.g.
> >
> > size_t odp_cpumask_to_str(const odp_cpumask_t *mask, char *str, size_t
> len);
> Better to use ssize_t then?

The point is that the same type is used for "len" and return value. Explicitly 
signed type for len would not be intuitive.

> 
> >
> >
> > size_t len, out;
> > char str[SIZE];
> >
> > len = sizeof(str);
> >
> > out = odp_cpumask_to_str(mask, str, len);
> >
> > if (out > len) {
> Simple yes. But we just defined the convention that we use negative
> values to indicate failures. Why not follow that here?
> To use positive values to indicate both success and error conditions
> seems confusing to me. snprintf is not a good example here.

The same, unsigned type - so that compiler does not complain when comparing 
those two.

size_t a;
ssize_t b;

if (a > b)

gcc -W -Wall ...

main.c:17:8: warning: comparison between signed and unsigned integer 
expressions [-Wsign-compare]
  if (a > b)


-Petri


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

Re: [lng-odp] odp_cpumask.h

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: ext Ola Liljedahl [mailto:ola.liljed...@linaro.org]
> Sent: Wednesday, January 28, 2015 1:29 PM
> To: Savolainen, Petri (NSN - FI/Espoo)
> Cc: LNG ODP Mailman List
> Subject: Re: [lng-odp] odp_cpumask.h
> 
> On 28 January 2015 at 12:21, Savolainen, Petri (NSN - FI/Espoo)
>  wrote:
> >
> >
> >> -Original Message-
> >> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> >> boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
> >> Sent: Wednesday, January 28, 2015 12:48 PM
> >> To: LNG ODP Mailman List
> >> Subject: [lng-odp] odp_cpumask.h
> >>
> >>  * @param strOutput buffer
> >>  * @param lenSize of string length (incl. ending zero)
> >>  */
> >> void odp_cpumask_to_str(const odp_cpumask_t *mask, char *str, int len);
> >>
> >> Why don't we use size_t for the"len" parameter?
> >>
> >> -- Ola
> >
> >
> > It's an object size, so it can be changed to size_t (similar to e.g.
> snprintf()).
> >
> > Packet data len/offsets, buffer sizes, packet/bytes counts etc, should
> be uintxx_t - but object sizes should be size_t.
> >
> >
> > Answer to: What happens if len < output length? Maybe we copy the
> snprintf definition (except output also ending zero). Return number chars
> written (incl. str ending zero), otherwise return number of chars that
> would have been outputted (return >len and clip output).
> This is more complicated to check for and goes against the convention
> of returning <0 for errors.
> I would prefer my suggestion with returning -(minimum required buffer
> size), there's a clear separation between success and error.
> 
> And that we add a define with a suggested buffer size which will be
> usable when the CPU mask is full (all bits set), this seems to be 128
> when using Linux cpu_set_t for the implementation. Of course ODP could
> use a smaller max size as well.


About error from functions that return len. I'd have input param and return 
type the same, so that compiler don't complain when comparing those (maybe your 
audio was breaking on call yesterday on that part).

e.g.

size_t odp_cpumask_to_str(const odp_cpumask_t *mask, char *str, size_t len);


size_t len, out;
char str[SIZE];

len = sizeof(str);

out = odp_cpumask_to_str(mask, str, len);

if (out > len) {
printf("output needs %z chars", out);
   ABORT();
}


-Petri


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

Re: [lng-odp] odp_cpumask.h

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
> Sent: Wednesday, January 28, 2015 12:48 PM
> To: LNG ODP Mailman List
> Subject: [lng-odp] odp_cpumask.h
> 
>  * @param strOutput buffer
>  * @param lenSize of string length (incl. ending zero)
>  */
> void odp_cpumask_to_str(const odp_cpumask_t *mask, char *str, int len);
> 
> Why don't we use size_t for the"len" parameter?
> 
> -- Ola


It's an object size, so it can be changed to size_t (similar to e.g. 
snprintf()).

Packet data len/offsets, buffer sizes, packet/bytes counts etc, should be 
uintxx_t - but object sizes should be size_t.


Answer to: What happens if len < output length? Maybe we copy the snprintf 
definition (except output also ending zero). Return number chars written (incl. 
str ending zero), otherwise return number of chars that would have been 
outputted (return >len and clip output).

-Petri

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

Re: [lng-odp] [PATCH] api: packet: odp_packet_flags spec changes

[Savolainen, Petri (NSN - FI/Espoo)]

Reviewed-by: Petri Savolainen 

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Bill Fischofer
> Sent: Wednesday, January 28, 2015 12:37 AM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCH] api: packet: odp_packet_flags spec changes
> 
> Change odp_packet_error() to odp_packet_has_error() and delete
> odp_packet_errflag_frame_len() per v1.0 delta doc.
> 
> Signed-off-by: Bill Fischofer 
> ---
>  example/generator/odp_generator.c |  2 +-
>  example/ipsec/odp_ipsec.c |  2 +-
>  example/l2fwd/odp_l2fwd.c |  2 +-
>  example/packet/odp_pktio.c|  2 +-
>  platform/linux-generic/include/api/odp_packet_flags.h | 13 +++--
>  platform/linux-generic/odp_packet_flags.c |  9 +
>  test/validation/buffer/odp_packet_test.c  |  5 +
>  test/validation/odp_pktio.c   |  2 +-
>  8 files changed, 10 insertions(+), 27 deletions(-)
> 
> diff --git a/example/generator/odp_generator.c
> b/example/generator/odp_generator.c
> index 492664e..ad62e08 100644
> --- a/example/generator/odp_generator.c
> +++ b/example/generator/odp_generator.c
> @@ -522,7 +522,7 @@ static void *gen_recv_thread(void *arg)
> 
>   pkt = odp_packet_from_event(ev);
>   /* Drop packets with errors */
> - if (odp_unlikely(odp_packet_error(pkt))) {
> + if (odp_unlikely(odp_packet_has_error(pkt))) {
>   odp_packet_free(pkt);
>   continue;
>   }
> diff --git a/example/ipsec/odp_ipsec.c b/example/ipsec/odp_ipsec.c
> index f2d2fc7..22fddb2 100644
> --- a/example/ipsec/odp_ipsec.c
> +++ b/example/ipsec/odp_ipsec.c
> @@ -616,7 +616,7 @@ static
>  pkt_disposition_e do_input_verify(odp_packet_t pkt,
> pkt_ctx_t *ctx EXAMPLE_UNUSED)
>  {
> - if (odp_unlikely(odp_packet_error(pkt)))
> + if (odp_unlikely(odp_packet_has_error(pkt)))
>   return PKT_DROP;
> 
>   if (!odp_packet_has_eth(pkt))
> diff --git a/example/l2fwd/odp_l2fwd.c b/example/l2fwd/odp_l2fwd.c
> index 18403da..305d9ae 100644
> --- a/example/l2fwd/odp_l2fwd.c
> +++ b/example/l2fwd/odp_l2fwd.c
> @@ -424,7 +424,7 @@ static int drop_err_pkts(odp_packet_t pkt_tbl[],
> unsigned len)
>   for (i = 0, j = 0; i < len; ++i) {
>   pkt = pkt_tbl[i];
> 
> - if (odp_unlikely(odp_packet_error(pkt))) {
> + if (odp_unlikely(odp_packet_has_error(pkt))) {
>   odp_packet_free(pkt); /* Drop */
>   pkt_cnt--;
>   } else if (odp_unlikely(i != j++)) {
> diff --git a/example/packet/odp_pktio.c b/example/packet/odp_pktio.c
> index c4c720b..1972dfa 100644
> --- a/example/packet/odp_pktio.c
> +++ b/example/packet/odp_pktio.c
> @@ -408,7 +408,7 @@ static int drop_err_pkts(odp_packet_t pkt_tbl[],
> unsigned len)
>   for (i = 0, j = 0; i < len; ++i) {
>   pkt = pkt_tbl[i];
> 
> - if (odp_unlikely(odp_packet_error(pkt))) {
> + if (odp_unlikely(odp_packet_has_error(pkt))) {
>   odp_packet_free(pkt); /* Drop */
>   pkt_cnt--;
>   } else if (odp_unlikely(i != j++)) {
> diff --git a/platform/linux-generic/include/api/odp_packet_flags.h
> b/platform/linux-generic/include/api/odp_packet_flags.h
> index 24c4065..c239a28 100644
> --- a/platform/linux-generic/include/api/odp_packet_flags.h
> +++ b/platform/linux-generic/include/api/odp_packet_flags.h
> @@ -32,17 +32,10 @@ extern "C" {
>   * Checks all error flags at once.
>   *
>   * @param pkt Packet handle
> - * @return 1 if packet has errors, 0 otherwise
> + * @retval 1 packet has errors
> + * @retval 0 packet has no errors
>   */
> -int odp_packet_error(odp_packet_t pkt);
> -
> -/**
> - * Check if error was 'frame length' error
> - *
> - * @param pkt Packet handle
> - * @return 1 if frame length error detected, 0 otherwise
> - */
> -int odp_packet_errflag_frame_len(odp_packet_t pkt);
> +int odp_packet_has_error(odp_packet_t pkt);
> 
>  /**
>   * Check for L2 header, e.g. ethernet
> diff --git a/platform/linux-generic/odp_packet_flags.c b/platform/linux-
> generic/odp_packet_flags.c
> index 3f0ea9f..e678f66 100644
> --- a/platform/linux-generic/odp_packet_flags.c
> +++ b/platform/linux-generic/odp_packet_flags.c
> @@ -8,18 +8,11 @@
>  #include 
> 
> 
> -int odp_packet_error(odp_packet_t pkt)
> +int odp_packet_has_error(odp_packet_t pkt)
>  {
>   return (odp_packet_hdr(pkt)->error_flags.all != 0);
>  }
> 
> -/* Get Error Flags */
> -
> -int odp_packet_errflag_frame_len(odp_packet_t pkt)
> -{
> - return odp_packet_hdr(pkt)->error_flags.frame_len;
> -}
> -
>  /* Get Input Flags */
> 
>  int odp_packet_has_l2(odp_packet_t pkt)
> diff --git a/test/validation/buffer/odp_packet_test.c
> b/test/validation/b

Re: [lng-odp] [PATCH] api: unify @return/@retval descriptions and return types

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
> Sent: Tuesday, January 27, 2015 2:44 PM
> To: Bill Fischofer
> Cc: LNG ODP Mailman List
> Subject: Re: [lng-odp] [PATCH] api: unify @return/@retval descriptions and
> return types
> 
> On 27 January 2015 at 12:52, Bill Fischofer 
> wrote:
> > I think it's good practice for functions to be robust in parameter
> handling
> > unless they are expected to be used in performance paths.  That's the
> reason
> > why we've said that things like odp_buffer_addr() etc. have undefined
> > behavior if they're passed invalid handles.  But shm and pools are
> things
> > that will typically get set up once during init, and seldom changed
> (maybe
> > as part of reconfig) so the performance argument is less compelling
> there.
> I agree but this is not only about performance. Sprinkling the API's
> with error codes also forces the user to check those return values
> which complicates the application logic and probably creates code that
> will be difficult to get test coverage for. I have a lot of experience
> with API's that cannot return errors and I really prefer this style.
> Applications becomes so much simpler.
> 
> Why should odp_shm_addr() be allowed to return an error code? Most
> implementations most likely will not even utilize the possibility and
> applications will not expect an error to happen and so might not even
> check the return value. How often do you check the return value of
> printf or close?
> 
> Just because the functions do not have to check for valid parameters
> so that they can return corresponding error indications does not mean
> that implementations cannot and should not check for (in)valid
> parameters. But if invalid parameters are detected, the error has to
> be signaled in some other way, e.g. by calling ODP_ABORT (as ODP
> doesn't have any error handling mechanism for users to hook into).
> 
> The timer implementation always checks timer pool handles and timer
> handles for validity. As ODP_ABORT (which does not return control to
> the caller) is used to report invalid parameters, the applications
> cannot rely on the ODP implementation handling invalid parameters. In
> another implementation, the checks could be removed with no change of
> semantics. As you say that should only be considered for truly
> performance critical functions.
> 
> 


I have also experience with (the same) API that cannot return errors and didn't 
like it always. Sometimes application has better idea about the severity of the 
failure and could prefer to back off or retry (the API call), instead of just 
crashing right there.

Also if every call fails through an error handler, it will contain large part 
of the application logic (without exact information about the error context).

There's a difference if a call failed due to a corrupt handle, or if the 
resource was freed/become unusable in parallel (timing / status failure). The 
first, should crash right there, the second could return failure (and 
application could decide what to do next). 


-Petri


  



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

Re: [lng-odp] [PATCH v5 01/17] api: event: Add odp_event_t

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: ext Ciprian Barbu [mailto:ciprian.ba...@linaro.org]
> Sent: Tuesday, January 27, 2015 2:21 PM
> To: Bill Fischofer
> Cc: Petri Savolainen; lng-odp
> Subject: Re: [lng-odp] [PATCH v5 01/17] api: event: Add odp_event_t
> 
> On Tue, Jan 27, 2015 at 2:14 PM, Bill Fischofer
>  wrote:
> > Values of ODP abstract types are implementation defined and hence
> arbitrary.
> > Implementations are free to define them in whatever way is most
> efficient
> > for them.
> 
> The question was not about efficiency, enums should be just as
> efficient, I was trying to point out a possible problem. When an event
> will be used in an application inside a structure it will most likely
> be memset to 0, it makes more sense to have ODP_EVENT_TYPE_INVALID.
> 


I used identical values with old buffer type values (to avoid transition 
problems). Buffer type any was removed, which had value 0. Implementation (and 
values) can be updated any time after merge.

I also prefer that all invalid values are defined to zero, so that memset(x, 0, 
sizeof(x)) produces invalid value.


-Petri

 

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

Re: [lng-odp] [PATCH v5 07/17] api: packet: Removed odp_packet_to_buffer

[Savolainen, Petri (NSN - FI/Espoo)]

I don’t have time to rebase it today. I’d propose to revert the conflicting 
patch from the repo and rebase that instead. It saves a day or two, plus stops 
conflicting new development (usage of buffers instead of events).

- Petri

From: ext Bill Fischofer [mailto:bill.fischo...@linaro.org]
Sent: Tuesday, January 27, 2015 12:17 AM
To: Mike Holmes
Cc: Petri Savolainen; lng-odp
Subject: Re: [lng-odp] [PATCH v5 07/17] api: packet: Removed 
odp_packet_to_buffer

We need to halt merges until events are merged.  That's why it's critical path. 
 We should be able to fix this as a one-off but we can't keep rebasing it.  
Everything else should rebase on events.

We'll have the same merge-barrier "all stop" issue with the API directory 
change.

Bill

On Mon, Jan 26, 2015 at 3:57 PM, Mike Holmes 
mailto:mike.hol...@linaro.org>> wrote:
This no longer applies to tip

classification/odp_classification_tests.c: In function ‘enqueue_loop_interface’:
classification/odp_classification_tests.c:108:2: error: implicit declaration of 
function ‘odp_packet_to_buffer’ [-Werror=implicit-function-declaration]
  odp_queue_enq(defqueue, odp_packet_to_buffer(pkt));
  ^
classification/odp_classification_tests.c:108:2: error: nested extern 
declaration of ‘odp_packet_to_buffer’ [-Werror=nested-externs]


On 26 January 2015 at 08:05, Petri Savolainen 
mailto:petri.savolai...@linaro.org>> wrote:
Removed packet to buffer conversion.

packet -> event -> buffer conversions are temporary.

Signed-off-by: Petri Savolainen 
mailto:petri.savolai...@linaro.org>>
---
 example/generator/odp_generator.c| 2 +-
 example/ipsec/odp_ipsec.c| 8 
 platform/linux-generic/include/api/odp_packet.h  | 9 -
 platform/linux-generic/include/odp_packet_internal.h | 9 +
 platform/linux-generic/odp_crypto.c  | 4 ++--
 platform/linux-generic/odp_packet.c  | 2 +-
 platform/linux-generic/odp_packet_io.c   | 6 +++---
 test/validation/buffer/odp_packet_test.c | 2 +-
 8 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/example/generator/odp_generator.c 
b/example/generator/odp_generator.c
index 547366a..5df8868 100644
--- a/example/generator/odp_generator.c
+++ b/example/generator/odp_generator.c
@@ -448,7 +448,7 @@ static void print_pkts(int thr, odp_packet_t pkt_tbl[], 
unsigned len)

odp_atomic_inc_u64(&counters.ip);
rlen += sprintf(msg, "receive Packet proto:IP ");
-   buf = odp_buffer_addr(odp_packet_to_buffer(pkt));
+   buf = odp_packet_data(pkt);
ip = (odph_ipv4hdr_t *)(buf + odp_packet_l3_offset(pkt));
rlen += sprintf(msg + rlen, "id %d ",
odp_be_to_cpu_16(ip->id));
diff --git a/example/ipsec/odp_ipsec.c b/example/ipsec/odp_ipsec.c
index a59794a..9fdaeab 100644
--- a/example/ipsec/odp_ipsec.c
+++ b/example/ipsec/odp_ipsec.c
@@ -740,7 +740,7 @@ pkt_disposition_e do_ipsec_in_classify(odp_packet_t pkt,
*skip = FALSE;
if (odp_crypto_operation(¶ms,
 &posted,
-odp_packet_to_buffer(pkt))) {
+
odp_buffer_from_event(odp_packet_to_event(pkt {
abort();
}
return (posted) ? PKT_POSTED : PKT_CONTINUE;
@@ -766,7 +766,7 @@ pkt_disposition_e do_ipsec_in_finish(odp_packet_t pkt,
int trl_len = 0;

/* Check crypto result */
-   event = odp_packet_to_buffer(pkt);
+   event = odp_buffer_from_event(odp_packet_to_event(pkt));
odp_crypto_get_operation_compl_status(event, &auth_rc, &cipher_rc);
if (!is_crypto_compl_status_ok(&cipher_rc))
return PKT_DROP;
@@ -974,7 +974,7 @@ pkt_disposition_e do_ipsec_out_seq(odp_packet_t pkt,
/* Issue crypto request */
if (odp_crypto_operation(&ctx->ipsec.params,
 &posted,
-odp_packet_to_buffer(pkt))) {
+
odp_buffer_from_event(odp_packet_to_event(pkt {
abort();
}
return (posted) ? PKT_POSTED : PKT_CONTINUE;
@@ -998,7 +998,7 @@ pkt_disposition_e do_ipsec_out_finish(odp_packet_t pkt,
odph_ipv4hdr_t *ip;

/* Check crypto result */
-   event = odp_packet_to_buffer(pkt);
+   event = odp_buffer_from_event(odp_packet_to_event(pkt));
odp_crypto_get_operation_compl_status(event, &auth_rc, &cipher_rc);
if (!is_crypto_compl_status_ok(&cipher_rc))
return PKT_DROP;
diff --git a/platform/linux-generic/include/api/odp_packet.h 
b/platform/linux-generic/include/api/odp_packet.h
index 92b6016..fa3e321 100644
--- a/platform/linux-generic/include/api/odp_packet.h
+++ b/platform/linux-generic/include/api/odp_packet.h
@@ -105,15 +105,6 @@ int odp_packet_reset(odp_packet_t pkt, uint32_t len);
 odp_packet_t odp_packe

Re: [lng-odp] questions on odp_generator - threads vs. processes

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: ext Ola Liljedahl [mailto:ola.liljed...@linaro.org]
> Sent: Monday, January 26, 2015 3:37 PM
> To: Savolainen, Petri (NSN - FI/Espoo)
> Cc: Maxim Uvarov; LNG ODP Mailman List
> Subject: Re: [lng-odp] questions on odp_generator - threads vs. processes
> 
> On 26 January 2015 at 14:27, Savolainen, Petri (NSN - FI/Espoo)
>  wrote:
> >
> >
> >> -Original Message-
> >> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> >> boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
> >> Sent: Monday, January 26, 2015 2:52 PM
> >> To: Maxim Uvarov
> >> Cc: LNG ODP Mailman List
> >> Subject: Re: [lng-odp] questions on odp_generator - threads vs.
> processes
> >>
> >> On 26 January 2015 at 13:23, Maxim Uvarov 
> wrote:
> >> > Ola, I think it's was there since first version and copy pasted from
> >> first
> >> > example app. In this particular case arguments can be simple
> allocated
> >> with
> >> > malloc. And this memory will be visible, does not matter fork() or
> >> > pthread_create() will be used after.
> >> Yes it seems like overkill to allocate all memory as shared memory
> >> regions (which have some overhead, especially in the kernel). Unless
> >> we create a malloc-like memory allocator and make it use a shared
> >> memory region.
> >>
> >> Petri once claimed that ODP implementations need to use shared memory
> >> regions in order to support multi-process model. But there is also a
> >> fair amount of static data used (e.g. for lookup from handle to e.g.
> >> buffer or timer pool etc). I assume only in the case of using fork
> >> will the multi-process model work.
> >
> > An application should use shared memory if it needs to be portable
> across pthreads/forked-processes/multi-processes/bare metal (that would be
> a nice demo / example). Some implementations could support multi-process
> model (e.g. DPDK) or bare metal, although linux-generic does not do that
> currently.
> What is not clear is if this portability (to bare metal and/or
> multi-process environments) comes from (specifically) using ODP shared
> memory or it comes from avoiding using non-portable API's (like malloc
> except malloc is part of StdC so should always be available if you
> have a StdC compiler which is required by ODP anyway) and only use ODP
> functionality.

You cannot allocate shared memory with malloc on multi-process model, or inside 
forked processes (after the fork) and on bare metal it depends (if it's per 
core or shared). Odp_shm_reserve() would work in all of those cases.

-Petri


> 
> >
> >
> > -Petri
> >
> >
> >
> >>
> >>
> >> >
> >> > regards,
> >> > Maxim.
> >> >
> >> >
> >> >
> >> > On 01/26/2015 02:47 PM, Ola Liljedahl wrote:
> >> >>
> >> >>  /* Reserve memory for args from shared mem */
> >> >>  shm = odp_shm_reserve("shm_args", sizeof(args_t),
> >> >>ODP_CACHE_LINE_SIZE, 0);
> >> >>  if (shm == ODP_SHM_INVALID) {
> >> >>  EXAMPLE_ERR("Error: shared mem alloc failed.\n");
> >> >>  exit(EXIT_FAILURE);
> >> >>  }
> >> >>  args = odp_shm_addr(shm);
> >> >>
> >> >> Why is odp_generator allocating argument storage as shared memory?
> >> >> "args" might be shared by the worker threads (or processes?). But
> some
> >> >> of the argument values are allocated through malloc/calloc which
> seems
> >> >> to defeat the goal of worker processes (instead of worker threads).
> >> >> The generator is always creating worker threads and seems not to
> have
> >> >> any option for worker processes.
> >> >>
> >> >>  odp_cpumask_zero(&thd_mask);
> >> >>  odp_cpumask_set(&thd_mask, cpu);
> >> >>  odph_linux_pthread_create(&thread_tbl[i],
> >> >>&thd_mask,
> >> >>thr_run_func,
> >> >>&args-
> >thread[i]);
> >> >> 

Re: [lng-odp] [PATCHv6] hugepages: align mmap size for hugepages

[Savolainen, Petri (NSN - FI/Espoo)]

Reviewed-by: Petri Savolainen 


ODP_DBG("odp_shm_reserve: mmap HP failed\n") is still there but we can remove 
it later if it get annoying on some configurations.


-Petri


> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Maxim Uvarov
> Sent: Monday, January 26, 2015 2:55 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv6] hugepages: align mmap size for hugepages
> 
> In case of hugepages munmap requires size aligned to page.
> 
> Signed-off-by: Maxim Uvarov 
> ---
>  v6: error if ftuncate fails in HP case.
> 
>  platform/linux-generic/odp_shared_memory.c | 73 +++--
> -
>  test/validation/odp_shm.c  |  4 ++
>  2 files changed, 51 insertions(+), 26 deletions(-)
> 
> diff --git a/platform/linux-generic/odp_shared_memory.c b/platform/linux-
> generic/odp_shared_memory.c
> index 23a9ceb..515a26f 100644
> --- a/platform/linux-generic/odp_shared_memory.c
> +++ b/platform/linux-generic/odp_shared_memory.c
> @@ -179,27 +179,31 @@ odp_shm_t odp_shm_reserve(const char *name, uint64_t
> size, uint64_t align,
>   int map_flag = MAP_SHARED;
>   /* If already exists: O_EXCL: error, O_TRUNC: truncate to zero */
>   int oflag = O_RDWR | O_CREAT | O_TRUNC;
> - uint64_t alloc_size = size + align;
> + uint64_t alloc_size;
>   uint64_t page_sz, huge_sz;
> +#ifdef MAP_HUGETLB
> + int need_huge_page = 0;
> + uint64_t alloc_hp_size;
> +#endif
> 
> - huge_sz = odp_sys_huge_page_size();
>   page_sz = odp_sys_page_size();
> + alloc_size = size + align;
> +
> +#ifdef MAP_HUGETLB
> + huge_sz = odp_sys_huge_page_size();
> + need_huge_page =  (huge_sz && alloc_size > page_sz);
> + /* munmap for huge pages requires sizes round up by page */
> + alloc_hp_size = (size + align + (huge_sz - 1)) & (-huge_sz);
> +#endif
> 
>   if (flags & ODP_SHM_PROC) {
>   /* Creates a file to /dev/shm */
>   fd = shm_open(name, oflag,
> S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
> -
>   if (fd == -1) {
>   ODP_DBG("odp_shm_reserve: shm_open failed\n");
>   return ODP_SHM_INVALID;
>   }
> -
> - if (ftruncate(fd, alloc_size) == -1) {
> - ODP_DBG("odp_shm_reserve: ftruncate failed\n");
> - return ODP_SHM_INVALID;
> - }
> -
>   } else {
>   map_flag |= MAP_ANONYMOUS;
>   }
> @@ -230,32 +234,50 @@ odp_shm_t odp_shm_reserve(const char *name, uint64_t
> size, uint64_t align,
>   block = &odp_shm_tbl->block[i];
> 
>   block->hdl  = to_handle(i);
> - block->huge = 0;
>   addr= MAP_FAILED;
> 
>  #ifdef MAP_HUGETLB
>   /* Try first huge pages */
> - if (huge_sz && alloc_size > page_sz) {
> - addr = mmap(NULL, alloc_size, PROT_READ | PROT_WRITE,
> - map_flag | MAP_HUGETLB, fd, 0);
> + if (need_huge_page) {
> + if ((flags & ODP_SHM_PROC) &&
> + (ftruncate(fd, alloc_hp_size) == -1)) {
> + odp_spinlock_unlock(&odp_shm_tbl->lock);
> + ODP_DBG("odp_shm_reserve: ftruncate HP failed\n");
> + return ODP_SHM_INVALID;
> + }
> +
> + addr = mmap(NULL, alloc_hp_size, PROT_READ | PROT_WRITE,
> + map_flag | MAP_HUGETLB, fd, 0);
> + if (addr == MAP_FAILED) {
> + ODP_DBG("odp_shm_reserve: mmap HP failed\n");
> + } else {
> + block->alloc_size = alloc_hp_size;
> + block->huge = 1;
> + block->page_sz = huge_sz;
> + }
>   }
>  #endif
> 
>   /* Use normal pages for small or failed huge page allocations */
>   if (addr == MAP_FAILED) {
> - addr = mmap(NULL, alloc_size, PROT_READ | PROT_WRITE,
> - map_flag, fd, 0);
> - block->page_sz = page_sz;
> - } else {
> - block->huge= 1;
> - block->page_sz = huge_sz;
> - }
> + if ((flags & ODP_SHM_PROC) &&
> + (ftruncate(fd, alloc_size) == -1)) {
> + odp_spinlock_unlock(&odp_shm_tbl->lock);
> + ODP_ERR("odp_shm_reserve: ftruncate failed\n");
> + return ODP_SHM_INVALID;
> + }
> 
> - if (addr == MAP_FAILED) {
> - /* Alloc failed */
> - odp_spinlock_unlock(&odp_shm_tbl->lock);
> - ODP_DBG("odp_shm_reserve: mmap failed\n");
> - return ODP_SHM_INVALID;
> + addr = mmap(NULL, alloc_size, PROT_READ | PROT_WRITE,
> + map_flag, fd, 0);
> + if (addr == MAP_FAILED) {
> + odp_spinlock_unlock(&odp_shm_tbl->lock);
> + O

Re: [lng-odp] questions on odp_generator - threads vs. processes

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
> Sent: Monday, January 26, 2015 2:52 PM
> To: Maxim Uvarov
> Cc: LNG ODP Mailman List
> Subject: Re: [lng-odp] questions on odp_generator - threads vs. processes
> 
> On 26 January 2015 at 13:23, Maxim Uvarov  wrote:
> > Ola, I think it's was there since first version and copy pasted from
> first
> > example app. In this particular case arguments can be simple allocated
> with
> > malloc. And this memory will be visible, does not matter fork() or
> > pthread_create() will be used after.
> Yes it seems like overkill to allocate all memory as shared memory
> regions (which have some overhead, especially in the kernel). Unless
> we create a malloc-like memory allocator and make it use a shared
> memory region.
> 
> Petri once claimed that ODP implementations need to use shared memory
> regions in order to support multi-process model. But there is also a
> fair amount of static data used (e.g. for lookup from handle to e.g.
> buffer or timer pool etc). I assume only in the case of using fork
> will the multi-process model work.

An application should use shared memory if it needs to be portable across 
pthreads/forked-processes/multi-processes/bare metal (that would be a nice demo 
/ example). Some implementations could support multi-process model (e.g. DPDK) 
or bare metal, although linux-generic does not do that currently.


-Petri



> 
> 
> >
> > regards,
> > Maxim.
> >
> >
> >
> > On 01/26/2015 02:47 PM, Ola Liljedahl wrote:
> >>
> >>  /* Reserve memory for args from shared mem */
> >>  shm = odp_shm_reserve("shm_args", sizeof(args_t),
> >>ODP_CACHE_LINE_SIZE, 0);
> >>  if (shm == ODP_SHM_INVALID) {
> >>  EXAMPLE_ERR("Error: shared mem alloc failed.\n");
> >>  exit(EXIT_FAILURE);
> >>  }
> >>  args = odp_shm_addr(shm);
> >>
> >> Why is odp_generator allocating argument storage as shared memory?
> >> "args" might be shared by the worker threads (or processes?). But some
> >> of the argument values are allocated through malloc/calloc which seems
> >> to defeat the goal of worker processes (instead of worker threads).
> >> The generator is always creating worker threads and seems not to have
> >> any option for worker processes.
> >>
> >>  odp_cpumask_zero(&thd_mask);
> >>  odp_cpumask_set(&thd_mask, cpu);
> >>  odph_linux_pthread_create(&thread_tbl[i],
> >>&thd_mask,
> >>thr_run_func,
> >>&args->thread[i]);
> >>  cpu = odp_cpumask_next(&cpumask, cpu);
> >>
> >>
> >> When parsing the command line arguments in the main thread:
> >>  /* allocate storage for the if names */
> >>  appl_args->if_names =
> >>  calloc(appl_args->if_count, sizeof(char
> *));
> >>
> >> Setting up per-thread arguments:
> >>  args->thread[i].pktio_dev =
> >> args->appl.if_names[if_idx]
> >>
> >> In the worker threads:
> >>  pktio = odp_pktio_lookup(thr_args->pktio_dev);
> >>
> >> /** * Thread specific arguments
> >>   */
> >> typedef struct {
> >>  char *pktio_dev;/**< Interface name to use */
> >>  odp_buffer_pool_t pool; /**< Buffer pool for packet IO */
> >>  int mode;   /**< Thread mode */
> >> } thread_args_t;
> >>
> >> ___
> >> lng-odp mailing list
> >> lng-odp@lists.linaro.org
> >> http://lists.linaro.org/mailman/listinfo/lng-odp
> >
> >
> >
> > ___
> > lng-odp mailing list
> > lng-odp@lists.linaro.org
> > http://lists.linaro.org/mailman/listinfo/lng-odp
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp

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

Re: [lng-odp] [PATCHv5] hugepages: align mmap size for hugepages

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Maxim Uvarov
> Sent: Monday, January 26, 2015 2:13 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv5] hugepages: align mmap size for hugepages
> 
> In case of hugepages munmap requires size aligned to page.
> 
> Signed-off-by: Maxim Uvarov 
> ---
>  v5: - fix alloc_hp_size define (somehow arm gcc finds that it can be
> uninitialized;
>  - remove goto and make if cases more readable;
> 
> 
>  platform/linux-generic/odp_shared_memory.c | 73 +++--
> -
>  test/validation/odp_shm.c  |  4 ++
>  2 files changed, 50 insertions(+), 27 deletions(-)
> 
> diff --git a/platform/linux-generic/odp_shared_memory.c b/platform/linux-
> generic/odp_shared_memory.c
> index 23a9ceb..4689c5d 100644
> --- a/platform/linux-generic/odp_shared_memory.c
> +++ b/platform/linux-generic/odp_shared_memory.c
> @@ -179,27 +179,32 @@ odp_shm_t odp_shm_reserve(const char *name, uint64_t
> size, uint64_t align,
>   int map_flag = MAP_SHARED;
>   /* If already exists: O_EXCL: error, O_TRUNC: truncate to zero */
>   int oflag = O_RDWR | O_CREAT | O_TRUNC;
> - uint64_t alloc_size = size + align;
> + uint64_t alloc_size;
>   uint64_t page_sz, huge_sz;
> + int ret;
> +#ifdef MAP_HUGETLB
> + int need_huge_page = 0;
> + uint64_t alloc_hp_size;
> +#endif
> 
> - huge_sz = odp_sys_huge_page_size();
>   page_sz = odp_sys_page_size();
> + alloc_size = size + align;
> +
> +#ifdef MAP_HUGETLB
> + huge_sz = odp_sys_huge_page_size();
> + need_huge_page =  (huge_sz && alloc_size > page_sz);
> + /* munmap for huge pages requires sizes round up by page */
> + alloc_hp_size = (size + align + (huge_sz - 1)) & (-huge_sz);
> +#endif
> 
>   if (flags & ODP_SHM_PROC) {
>   /* Creates a file to /dev/shm */
>   fd = shm_open(name, oflag,
> S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
> -
>   if (fd == -1) {
>   ODP_DBG("odp_shm_reserve: shm_open failed\n");
>   return ODP_SHM_INVALID;
>   }
> -
> - if (ftruncate(fd, alloc_size) == -1) {
> - ODP_DBG("odp_shm_reserve: ftruncate failed\n");
> - return ODP_SHM_INVALID;
> - }
> -
>   } else {
>   map_flag |= MAP_ANONYMOUS;
>   }
> @@ -230,32 +235,47 @@ odp_shm_t odp_shm_reserve(const char *name, uint64_t
> size, uint64_t align,
>   block = &odp_shm_tbl->block[i];
> 
>   block->hdl  = to_handle(i);
> - block->huge = 0;
>   addr= MAP_FAILED;
> 
>  #ifdef MAP_HUGETLB
>   /* Try first huge pages */
> - if (huge_sz && alloc_size > page_sz) {
> - addr = mmap(NULL, alloc_size, PROT_READ | PROT_WRITE,
> - map_flag | MAP_HUGETLB, fd, 0);
> + if (need_huge_page) {
> + ret = 0;
> + if (flags & ODP_SHM_PROC)
> + ret = ftruncate(fd, alloc_hp_size);


It's an error if ftruncate fails, so just return SHM_INVALID.

if (ftruncate(fd, alloc_hp_size) == -1) {
ODP_DBG("odp_shm_reserve: ftruncate failed\n");
return ODP_SHM_INVALID;
}


> +
> + if (ret == 0) {

This if-clause can be then removed...

> + addr = mmap(NULL, alloc_hp_size, PROT_READ | PROT_WRITE,
> + map_flag | MAP_HUGETLB, fd, 0);
> + if (addr == MAP_FAILED) {
> + ODP_DBG("odp_shm_reserve: mmap HP failed\n");

Depending on system / config there may be only e.g. 4 huge pages available. So 
it may be pretty common that you run out of huge pages and use normal pages 
instead. I'd leave the warning out from here.


> + } else {
> + block->alloc_size = alloc_hp_size;
> + block->huge = 1;
> + block->page_sz = huge_sz;
> + }
> + }
>   }
>  #endif
> 
>   /* Use normal pages for small or failed huge page allocations */
>   if (addr == MAP_FAILED) {
> - addr = mmap(NULL, alloc_size, PROT_READ | PROT_WRITE,
> - map_flag, fd, 0);
> - block->page_sz = page_sz;
> - } else {
> - block->huge= 1;
> - block->page_sz = huge_sz;
> - }
> -
> - if (addr == MAP_FAILED) {
> - /* Alloc failed */
> - odp_spinlock_unlock(&odp_shm_tbl->lock);
> - ODP_DBG("odp_shm_reserve: mmap failed\n");
> - return ODP_SHM_INVALID;
> + ret = 0;
> + if (flags & ODP_SHM_PROC)
> + ret = ftruncate(fd, alloc_size);

Same th

Re: [lng-odp] [PATCH v4 00/16] Event introduction

[Savolainen, Petri (NSN - FI/Espoo)]

After applying the shm_free bug fix, I can successfully run validation test 
suite in my system - both for the v0.9 and this patches on top of that pass (in 
each step). Didn’t see any failure (“make check”, odp_buffer and odp_timer) on 
any of the patches.

I can add 17th patch that modify scheduler implementation on those parts that 
exceed 80 chars.

-Petri


From: ext Bill Fischofer [mailto:bill.fischo...@linaro.org]
Sent: Sunday, January 25, 2015 12:57 AM
To: Petri Savolainen
Cc: LNG ODP Mailman List
Subject: Re: [lng-odp] [PATCH v4 00/16] Event introduction

I don't see any difference between this series and the v3 series.

Patch 0005 doesn't apply because it conflicts with an odp_schedule.c change 
made by update https://patches.linaro.org/43237/ that was merged in 0.9.0.  
I've posted a v5 level of this section that resolves that.

Patches 0002, 0004, 0005, 0007, and 0008 fail checkpatch due to >80 char line 
lengths.   Some of these are resolved in subsequent patches, but odp_schedule.c 
still has this problem after the last patch is applied.  We either need to 
change our policy on this globally or this series needs to be fixed to be in 
conformance with the agreed-to checkpatch rules.  I would vote for the former, 
but I'm in the minority.

I'm still seeing the odp_timer test fail after the application of patch 0013.  
All tests pass with the entire series applied, however.  I'm not sure why this 
is the case and I don't think it's critical.

With these caveats, for this series:

Reviewed-and-tested-by: Bill Fischofer 
mailto:bill.fischo...@linaro.org>>



On Fri, Jan 23, 2015 at 5:42 AM, Petri Savolainen 
mailto:petri.savolai...@linaro.org>> wrote:
This patch set introduces odp_event_t. It replaces odp_buffer_t in many places
with odp_event_t. Events are the objects that are transimitted by and scheduled
from queues. Event is the new "super class" for various events (buffers,
packets, timeouts, etc). Various event types can be converted to odp_event_t
(and back), but not to another event type.

Buffer pool is also changed to a generic "pool". Pool and event types have
been separated. There are matching pool types for buffer, packet and timeout
events (as "buffer types" before). Later on, there can be event types without
a matching pool type, and pool types without a matching event type.

Some lines are over 80 chars. Those are mainly caused by temporary
event <-> buffer, packet -> event -> buffer conversions and should be cleaned up
from the implementation. This patch set does minimal implementation changes.


v2
* Updated validation test suite to use events

v3
* Fixed bugs that crashed validation test cases
* Breaked over 80 char lines where possible (without re-implementation)

v4
* Fixed odp_buffer test to not test timeout alloc before it's implemented
* Corrected doxygen warnings


Petri Savolainen (16):
  api: event: Add odp_event_t
  api: event: odp_schedule and odp_queue_enq
  api: event: schedule_multi and queue_enq_multi
  api: event: odp_queue_deq
  api: event: odp_queue_deq_multi
  api: buffer: Removed odp_buffer_type
  api: packet: Removed odp_packet_to_buffer
  api: packet: Removed odp_packet_from_buffer
  api: timer: Use odp_event_t instead of odp_buffer_t
  api: crypto: Use odp_event_t instead of odp_buffer_t
  linux-generic: crypto: Use packet alloc for packet
  api: buffer_pool: Rename odp_buffer_pool.h to odp_pool.h
  api: pool: Rename pool params and remove buffer types
  api: pool: Rename odp_buffer_pool_ to odp_pool_
  api: config: Renamed ODP_CONFIG_BUFFER_POOLS
  api: timer: Added timeout alloc and free

 example/generator/odp_generator.c  |  38 ++--
 example/ipsec/odp_ipsec.c  |  70 +++
 example/ipsec/odp_ipsec_cache.c|   4 +-
 example/ipsec/odp_ipsec_cache.h|   2 +-
 example/ipsec/odp_ipsec_loop_db.c  |   2 +-
 example/ipsec/odp_ipsec_loop_db.h  |  12 +-
 example/ipsec/odp_ipsec_stream.c   |  20 +-
 example/ipsec/odp_ipsec_stream.h   |   2 +-
 example/l2fwd/odp_l2fwd.c  |  28 +--
 example/packet/odp_pktio.c |  29 ++-
 example/timer/odp_timer_test.c |  76 
 platform/linux-generic/Makefile.am |   4 +-
 platform/linux-generic/include/api/odp.h   |   3 +-
 platform/linux-generic/include/api/odp_buffer.h|  41 ++--
 .../linux-generic/include/api/odp_buffer_pool.h| 177 -
 .../linux-generic/include/api/odp_classification.h |   2 +-
 platform/linux-generic/include/api/odp_config.h|   4 +-
 platform/linux-generic/include/api/odp_crypto.h|  16 +-
 platform/linux-generic/include/api/odp_event.h |  59 ++
 platform/linux-generic/include/api/odp_packet.h|  27 +--
 platform/linux-generic/include/api/odp_packet_io.h |   4 +-
 .../linux-generic/include/api/odp_platform_types.h |  10 +-
 platform/linu

Re: [lng-odp] [PATCHv4 3/3] hugepages: align mmap size for hugepages

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: ext Maxim Uvarov [mailto:maxim.uva...@linaro.org]
> Sent: Friday, January 23, 2015 6:25 PM
> To: Savolainen, Petri (NSN - FI/Espoo); lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [PATCHv4 3/3] hugepages: align mmap size for
> hugepages
> 
> On 01/23/2015 04:54 PM, Savolainen, Petri (NSN - FI/Espoo) wrote:
> > More readable code with one if-clause and no goto:
> >
> > if (fd != -1 && ftruncate(fd, alloc_hp_size) != -1) {
> > addr = mmap(NULL, alloc_hp_size, PROT_READ | PROT_WRITE,
> > map_flag | MAP_HUGETLB, fd, 0);
> > }
> Petri, no that will not work. fd is only if ODP_SHM_PROC. But mmap
> hugepages should be done not depending ODP_SHM_PROC is provided or not.
> 
> Maxim.

OK. Anyway, I think it's better to return error if ftruncate() fails than try 
to recover from it. That error return would eliminate also need for that goto, 
which is good for readability.


-Petri


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

Re: [lng-odp] [PATCHv4 3/3] hugepages: align mmap size for hugepages

[Savolainen, Petri (NSN - FI/Espoo)]

Functionality OK. I'd reorganize the code a bit. See under.

Reviewed-by: Petri Savolainen 


> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Maxim Uvarov
> Sent: Friday, January 23, 2015 2:35 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv4 3/3] hugepages: align mmap size for hugepages
> 
> In case of hugepages munmap requires size aligned to page.
> 
> Signed-off-by: Maxim Uvarov 
> ---
>  v4: if alloc huge pages failed fall back to normal pages with original
> size.
> 
>  platform/linux-generic/odp_shared_memory.c | 43 +
> -
>  test/validation/odp_shm.c  |  4 +++
>  2 files changed, 34 insertions(+), 13 deletions(-)
> 
> diff --git a/platform/linux-generic/odp_shared_memory.c b/platform/linux-
> generic/odp_shared_memory.c
> index 23a9ceb..2004f30 100644
> --- a/platform/linux-generic/odp_shared_memory.c
> +++ b/platform/linux-generic/odp_shared_memory.c
> @@ -179,27 +179,32 @@ odp_shm_t odp_shm_reserve(const char *name, uint64_t
> size, uint64_t align,
>   int map_flag = MAP_SHARED;
>   /* If already exists: O_EXCL: error, O_TRUNC: truncate to zero */
>   int oflag = O_RDWR | O_CREAT | O_TRUNC;
> - uint64_t alloc_size = size + align;
> + uint64_t alloc_size;
> + uint64_t alloc_hp_size;
>   uint64_t page_sz, huge_sz;
> + int need_huge_page = 0;
> 
> - huge_sz = odp_sys_huge_page_size();
>   page_sz = odp_sys_page_size();
> + alloc_size = size + align;
> +
> +#ifdef MAP_HUGETLB
> + huge_sz = odp_sys_huge_page_size();
> + need_huge_page =  (huge_sz && alloc_size > page_sz);
> + if (need_huge_page) {
> + /* munmap for huge pages requires sizes round up by page */
> + alloc_hp_size = (size + align + (huge_sz - 1))
> +   & (-huge_sz);
> + }
> +#endif
> 
>   if (flags & ODP_SHM_PROC) {
>   /* Creates a file to /dev/shm */
>   fd = shm_open(name, oflag,
> S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
> -
>   if (fd == -1) {
>   ODP_DBG("odp_shm_reserve: shm_open failed\n");
>   return ODP_SHM_INVALID;
>   }
> -
> - if (ftruncate(fd, alloc_size) == -1) {
> - ODP_DBG("odp_shm_reserve: ftruncate failed\n");
> - return ODP_SHM_INVALID;
> - }
> -
>   } else {
>   map_flag |= MAP_ANONYMOUS;
>   }
> @@ -235,18 +240,31 @@ odp_shm_t odp_shm_reserve(const char *name, uint64_t
> size, uint64_t align,
> 
>  #ifdef MAP_HUGETLB
>   /* Try first huge pages */
> - if (huge_sz && alloc_size > page_sz) {
> - addr = mmap(NULL, alloc_size, PROT_READ | PROT_WRITE,
> + if (need_huge_page) {
> + if (flags & ODP_SHM_PROC) {
> + if (ftruncate(fd, alloc_hp_size) == -1)
> + goto normal_pages;
> + }
> + addr = mmap(NULL, alloc_hp_size, PROT_READ | PROT_WRITE,
>   map_flag | MAP_HUGETLB, fd, 0);
>   }
> +normal_pages:


More readable code with one if-clause and no goto:

if (fd != -1 && ftruncate(fd, alloc_hp_size) != -1) {
addr = mmap(NULL, alloc_hp_size, PROT_READ | PROT_WRITE,
map_flag | MAP_HUGETLB, fd, 0);
}



>  #endif
> -
>   /* Use normal pages for small or failed huge page allocations */
>   if (addr == MAP_FAILED) {
> + if (flags & ODP_SHM_PROC) {
> + if (ftruncate(fd, alloc_size) == -1) {
> + odp_spinlock_unlock(&odp_shm_tbl->lock);
> + ODP_DBG("odp_shm_reserve: ftruncate failed\n");
> + return ODP_SHM_INVALID;
> + }
> + }


Same reorganization here.

-Petri


>   addr = mmap(NULL, alloc_size, PROT_READ | PROT_WRITE,
>   map_flag, fd, 0);
> + block->alloc_size = alloc_size;
>   block->page_sz = page_sz;
>   } else {
> + block->alloc_size = alloc_hp_size;
>   block->huge= 1;
>   block->page_sz = huge_sz;
>   }
> @@ -267,7 +285,6 @@ odp_shm_t odp_shm_reserve(const char *name, uint64_t
> size, uint64_t align,
>   block->name[ODP_SHM_NAME_LEN - 1] = 0;
>   block->size   = size;
>   block->align  = align;
> - block->alloc_size = alloc_size;
>   block->flags  = flags;
>   block->fd = fd;
>   block->addr   = addr;
> diff --git a/test/validation/odp_shm.c b/test/validation/odp_shm.c
> index c26925b..4b1a38e 100644
> --- a/test/validation/odp_shm.c
> +++ b/test/validation/odp_shm.c
> @@ -32,7 +32,11 @@ static void *run_shm_thread(void *arg)
>   CU_ASSERT(0 

Re: [lng-odp] [PATCHv3 3/3] hugepages: align mmap size for hugepages

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Maxim Uvarov
> Sent: Thursday, January 22, 2015 6:39 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv3 3/3] hugepages: align mmap size for hugepages
> 
> In case of hugepages munmap requires size aligned to page.
> 
> Signed-off-by: Maxim Uvarov 
> ---
>  platform/linux-generic/odp_shared_memory.c | 18 ++
>  test/validation/odp_shm.c  |  4 
>  2 files changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/platform/linux-generic/odp_shared_memory.c b/platform/linux-
> generic/odp_shared_memory.c
> index 23a9ceb..d2b28bc 100644
> --- a/platform/linux-generic/odp_shared_memory.c
> +++ b/platform/linux-generic/odp_shared_memory.c
> @@ -179,11 +179,22 @@ odp_shm_t odp_shm_reserve(const char *name, uint64_t
> size, uint64_t align,
>   int map_flag = MAP_SHARED;
>   /* If already exists: O_EXCL: error, O_TRUNC: truncate to zero */
>   int oflag = O_RDWR | O_CREAT | O_TRUNC;
> - uint64_t alloc_size = size + align;
> + uint64_t alloc_size;
>   uint64_t page_sz, huge_sz;
> + int need_huge_page = 0;
> 
> - huge_sz = odp_sys_huge_page_size();
>   page_sz = odp_sys_page_size();
> + alloc_size = size + align;
> +
> +#ifdef MAP_HUGETLB
> + huge_sz = odp_sys_huge_page_size();
> + need_huge_page =  (huge_sz && alloc_size > page_sz);
> + if (need_huge_page) {
> + /* munmap for huge pages requires sizes round up by page */
> + alloc_size = (size + align + (huge_sz - 1))
> +   & (-huge_sz);
> + }
> +#endif
> 
>   if (flags & ODP_SHM_PROC) {
>   /* Creates a file to /dev/shm */
> @@ -235,12 +246,11 @@ odp_shm_t odp_shm_reserve(const char *name, uint64_t
> size, uint64_t align,
> 
>  #ifdef MAP_HUGETLB
>   /* Try first huge pages */
> - if (huge_sz && alloc_size > page_sz) {
> + if (need_huge_page) {
>   addr = mmap(NULL, alloc_size, PROT_READ | PROT_WRITE,
>   map_flag | MAP_HUGETLB, fd, 0);
>   }
>  #endif
> -

Small tuning still needed. Now if we are out of huge pages (mmap failed above), 
we want to fallback to use normal pages - with the original alloc_size. Huge 
page size maybe e.g. 1GB, so e.g. 5kB alloc_size would have been rounded up to 
1 GB. It needs to be reset here, so that we don't use excessive number of 
normal pages in the following mmap.

-Petri 


>   /* Use normal pages for small or failed huge page allocations */
>   if (addr == MAP_FAILED) {
>   addr = mmap(NULL, alloc_size, PROT_READ | PROT_WRITE,
> diff --git a/test/validation/odp_shm.c b/test/validation/odp_shm.c
> index c26925b..4b1a38e 100644
> --- a/test/validation/odp_shm.c
> +++ b/test/validation/odp_shm.c
> @@ -32,7 +32,11 @@ static void *run_shm_thread(void *arg)
>   CU_ASSERT(0 == info.flags);
>   CU_ASSERT(test_shared_data == info.addr);
>   CU_ASSERT(sizeof(test_shared_data_t) <= info.size);
> +#ifdef MAP_HUGETLB
> + CU_ASSERT(odp_sys_huge_page_size() == info.page_size);
> +#else
>   CU_ASSERT(odp_sys_page_size() == info.page_size);
> +#endif
>   odp_shm_print_all();
> 
>   fflush(stdout);
> --
> 1.8.5.1.163.gd7aced9
> 
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp

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

Re: [lng-odp] [PATCHv2 3/3] hugepages: align mmap size for hugepages

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Maxim Uvarov
> Sent: Thursday, January 22, 2015 5:45 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv2 3/3] hugepages: align mmap size for hugepages
> 
> In case of hugepages munmap requires size aligned to page.
> 
> Signed-off-by: Maxim Uvarov 
> ---
>  platform/linux-generic/odp_shared_memory.c | 12 ++--
>  test/validation/odp_shm.c  |  4 
>  2 files changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/platform/linux-generic/odp_shared_memory.c b/platform/linux-
> generic/odp_shared_memory.c
> index 23a9ceb..7adbe52 100644
> --- a/platform/linux-generic/odp_shared_memory.c
> +++ b/platform/linux-generic/odp_shared_memory.c
> @@ -179,12 +179,20 @@ odp_shm_t odp_shm_reserve(const char *name, uint64_t
> size, uint64_t align,
>   int map_flag = MAP_SHARED;
>   /* If already exists: O_EXCL: error, O_TRUNC: truncate to zero */
>   int oflag = O_RDWR | O_CREAT | O_TRUNC;
> - uint64_t alloc_size = size + align;
> + uint64_t alloc_size;
>   uint64_t page_sz, huge_sz;
> 
> - huge_sz = odp_sys_huge_page_size();
>   page_sz = odp_sys_page_size();
> 
> +#ifdef MAP_HUGETLB
> + huge_sz = odp_sys_huge_page_size();
> + /* munmap for huge pages requires sizes round up by page */
> + alloc_size = (size + align + (huge_sz - 1))
> +   & (-huge_sz);

Huge pages should be used only after certain size limit. Those are scarce 
resource (much less huge pages than normal 4 kB pages). Currently huge pages 
are used only if application tries to reserve more than a (4kB) page size. 

#ifdef MAP_HUGETLB
/* Try first huge pages */
if (huge_sz && alloc_size > page_sz) {
addr = mmap(NULL, alloc_size, PROT_READ | PROT_WRITE,
map_flag | MAP_HUGETLB, fd, 0);
}
#endif

So, alloc_size rounding up should go inside that if clause.

-Petri 


> +#else
> + alloc_size = size + align;
> +#endif
> +
>   if (flags & ODP_SHM_PROC) {
>   /* Creates a file to /dev/shm */
>   fd = shm_open(name, oflag,
> diff --git a/test/validation/odp_shm.c b/test/validation/odp_shm.c
> index c26925b..918a77b 100644
> --- a/test/validation/odp_shm.c
> +++ b/test/validation/odp_shm.c
> @@ -32,7 +32,11 @@ static void *run_shm_thread(void *arg)
>   CU_ASSERT(0 == info.flags);
>   CU_ASSERT(test_shared_data == info.addr);
>   CU_ASSERT(sizeof(test_shared_data_t) <= info.size);
> +#ifdef MAP_HUGETLB
>   CU_ASSERT(odp_sys_page_size() == info.page_size);
> +#else
> + CU_ASSERT(odp_sys_huge_page_size() == info.page_size);
> +#endif
>   odp_shm_print_all();
> 
>   fflush(stdout);
> --
> 1.8.5.1.163.gd7aced9
> 
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp

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

Re: [lng-odp] [PATCH] linux-generic: shm fix unmap for hugepages

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Maxim Uvarov
> Sent: Thursday, January 22, 2015 5:01 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCH] linux-generic: shm fix unmap for hugepages
> 
> In case of hugepages unmap has to be done with address aligned to
> page size. Also unmap() has to be done for address returned by mmap(),
> not for aligned address after that.
> 
> To reproduce original bug run:
> echo 4096 >  /proc/sys/vm/nr_hugepages
> make check
> 
> Signed-off-by: Maxim Uvarov 
> ---
>  platform/linux-generic/odp_shared_memory.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/platform/linux-generic/odp_shared_memory.c b/platform/linux-
> generic/odp_shared_memory.c
> index 99c5b40..51eba02 100644
> --- a/platform/linux-generic/odp_shared_memory.c
> +++ b/platform/linux-generic/odp_shared_memory.c
> @@ -134,8 +134,14 @@ int odp_shm_free(odp_shm_t shm)
>   odp_spinlock_lock(&odp_shm_tbl->lock);
>   shm_block = &odp_shm_tbl->block[i];
> 
> +#ifdef MAP_HUGETLB
> + /* round up alloc size by page */
> + alloc_size = (shm_block->size + (shm_block->page_sz - 1))
> +   & (-shm_block->page_sz);

Could you rebase this on top of my two patches. And then move this calculation 
to shm_reserve() side, so that the same size gets allocated, saved into 
block->alloc_size, and the freed here. 

-Petri

> +#else
>   alloc_size = shm_block->size + shm_block->align;
> - ret = munmap(shm_block->addr, alloc_size);
> +#endif
> + ret = munmap(shm_block->addr_orig, alloc_size);
>   if (0 != ret) {
>   ODP_DBG("odp_shm_free: munmap failed\n");
>   odp_spinlock_unlock(&odp_shm_tbl->lock);
> --
> 1.8.5.1.163.gd7aced9
> 
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp

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

Re: [lng-odp] [PATCH] validation: add odp_schedule_pause and odp_schedule_resume tests

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Ciprian Barbu
> Sent: Wednesday, January 14, 2015 3:36 PM
> To: Ola Liljedahl
> Cc: lng-odp
> Subject: Re: [lng-odp] [PATCH] validation: add odp_schedule_pause and
> odp_schedule_resume tests
> 
> On Wed, Jan 14, 2015 at 3:28 PM, Ola Liljedahl 
> wrote:
> > On 7 January 2015 at 20:41, Mike Holmes  wrote:
> >> I am unsure if I need to pay attention to this for 0.7.0
> > We need to have a decision (and implementation) for ODP 1.0 though.
> > Scheduling and its semantics are important aspects of ODP.
> 
> The odp_schedule_pause API is already documented and implemented, I
> didn't exactly catch from Petri if we will keep the behavior for 1.0,
> but what is the problem with covering this API in its current form for
> at least 0.7 and 0.8?


There are no plans to change schedule pause/resume API.

-Petri



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

Re: [lng-odp] [PATCHv3] linux-generic: Add odp_errno and adapt packet_io and timer implementations to use it

[Savolainen, Petri (NSN - FI/Espoo)]

Reviewed-by: Petri Savolainen 


> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Mario Torrecillas Rodriguez
> Sent: Wednesday, January 21, 2015 6:14 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv3] linux-generic: Add odp_errno and adapt
> packet_io and timer implementations to use it
> 
> Added odp_errno.c and odp_errno.h
> Changed odp_packet_io and odp_timer to use it.
> 
> Signed-off-by: Mario Torrecillas Rodriguez
> 
> ---
> (This code contribution is provided under the terms of agreement LES-LTM-
> 21309)
> 
> Changes from previous version:
> * Changed doxygen comment
> * Removed  from API file
> 
>  platform/linux-generic/Makefile.am |  2 +
>  platform/linux-generic/include/api/odp_errno.h | 60
> ++
>  platform/linux-generic/include/odp_internal.h  |  1 +
>  platform/linux-generic/odp_errno.c | 35 +++
>  platform/linux-generic/odp_packet_io.c |  2 +-
>  platform/linux-generic/odp_packet_socket.c | 17 
>  platform/linux-generic/odp_timer.c |  5 ++-
>  7 files changed, 119 insertions(+), 3 deletions(-)
>  create mode 100644 platform/linux-generic/include/api/odp_errno.h
>  create mode 100644 platform/linux-generic/odp_errno.c
> 
> diff --git a/platform/linux-generic/Makefile.am b/platform/linux-
> generic/Makefile.am
> index a699ea6..1b71b71 100644
> --- a/platform/linux-generic/Makefile.am
> +++ b/platform/linux-generic/Makefile.am
> @@ -19,6 +19,7 @@ include_HEADERS = \
> $(top_srcdir)/platform/linux-
> generic/include/api/odp_cpumask.h \
> $(top_srcdir)/platform/linux-
> generic/include/api/odp_crypto.h \
> $(top_srcdir)/platform/linux-generic/include/api/odp_debug.h
> \
> +   $(top_srcdir)/platform/linux-generic/include/api/odp_errno.h
> \
> $(top_srcdir)/platform/linux-generic/include/api/odp_hints.h
> \
> $(top_srcdir)/platform/linux-generic/include/api/odp_init.h
> \
> $(top_srcdir)/platform/linux-
> generic/include/api/odp_packet_flags.h \
> @@ -80,6 +81,7 @@ __LIB__libodp_la_SOURCES = \
>  odp_classification.c \
>  odp_cpumask.c \
>  odp_crypto.c \
> +odp_errno.c \
>  odp_init.c \
>  odp_impl.c \
>  odp_linux.c \
> diff --git a/platform/linux-generic/include/api/odp_errno.h
> b/platform/linux-generic/include/api/odp_errno.h
> new file mode 100644
> index 000..0157720
> --- /dev/null
> +++ b/platform/linux-generic/include/api/odp_errno.h
> @@ -0,0 +1,60 @@
> +/* Copyright (c) 2015, Linaro Limited
> + * All rights reserved.
> + *
> + * SPDX-License-Identifier:  BSD-3-Clause
> + */
> +
> +/**
> + * @file
> + *
> + * ODP errno API
> + */
> +
> +#ifndef ODP_ERRNO_H_
> +#define ODP_ERRNO_H_
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +/**
> +* Return latest ODP errno
> +*
> +* @return ODP errno
> +* @retval 0 No error
> +*/
> +int odp_errno(void);
> +
> +/**
> +* Set ODP errno to zero
> +*/
> +void odp_errno_zero(void);
> +
> +/**
> +* Print ODP errno
> +*
> +* Interprets the value of ODP errno as an error message, and prints it,
> +* optionally preceding it with the custom message specified in str.
> +*
> +* @param str NULL, or pointer to the string to be appended
> +*/
> +void odp_errno_print(const char *str);
> +
> +/**
> +* Error message string
> +*
> +* Interprets the value of ODP errno, generating a string with a
> +* message that describes the error.
> +* It uses the system definition of errno.
> +*
> +* @param errnum  Error code
> +*
> +* @retval Pointer to the string
> +*/
> +const char *odp_errno_str(int errnum);
> +
> +#ifdef __cplusplus
> +}
> +#endif
> +
> +#endif
> diff --git a/platform/linux-generic/include/odp_internal.h
> b/platform/linux-generic/include/odp_internal.h
> index 549d406..b953163 100644
> --- a/platform/linux-generic/include/odp_internal.h
> +++ b/platform/linux-generic/include/odp_internal.h
> @@ -18,6 +18,7 @@
>  extern "C" {
>  #endif
> 
> +extern __thread int __odp_errno;
> 
>  int odp_system_info_init(void);
> 
> diff --git a/platform/linux-generic/odp_errno.c b/platform/linux-
> generic/odp_errno.c
> new file mode 100644
> index 000..ba080e7
> --- /dev/null
> +++ b/platform/linux-generic/odp_errno.c
> @@ -0,0 +1,35 @@
> +/* Copyright (c) 2015, Linaro Limited
> + * All rights reserved.
> + *
> + * SPDX-License-Identifier:  BSD-3-Clause
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +__thread int __odp_errno;
> +
> +int odp_errno(void)
> +{
> + return __odp_errno;
> +}
> +
> +void odp_errno_zero(void)
> +{
> + __odp_errno = 0;
> +}
> +
> +void odp_errno_print(const char *str)
> +{
> + if (str != NULL)
> + printf("%s ", str);
> +
> +   

Re: [lng-odp] [PATCHv2] linux-generic: Add odp_errno and adapt packet_io and timer implementations to use it

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: ext Mario Torrecillas Rodriguez
> [mailto:mario.torrecillasrodrig...@arm.com]
> Sent: Tuesday, January 20, 2015 5:08 PM
> To: Savolainen, Petri (NSN - FI/Espoo); lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [PATCHv2] linux-generic: Add odp_errno and adapt
> packet_io and timer implementations to use it
> 
> Thanks for the review Petri. A short comment inlined.
> 
> On 20/01/2015 13:38, "Savolainen, Petri (NSN - FI/Espoo)"
>  wrote:
> 
> >
> >> --- /dev/null
> >> +++ b/platform/linux-generic/include/api/odp_errno.h
> >> @@ -0,0 +1,61 @@
> >> +/* Copyright (c) 2015, Linaro Limited
> >> + * All rights reserved.
> >> + *
> >> + * SPDX-License-Identifier: BSD-3-Clause
> >> + */
> >> +
> >> +/**
> >> + * @file
> >> + *
> >> + * ODP errno API
> >> + */
> >> +
> >> +#ifndef ODP_ERRNO_H_
> >> +#define ODP_ERRNO_H_
> >> +
> >> +#ifdef __cplusplus
> >> +extern "C" {
> >> +#endif
> >> +
> >> +#include 
> >
> >This should be removed from API file (only implementation needs it).
> That¹s there so that both ODP libraries and applications using them can
> see the errno error definitions. Otherwise things like ³EEXIST² etc will
> give compile errors. The alternative would be to include both
>  and  in implementation files and applications.
> Which option should we go with?

I'd leave it out for now.

The problem is that errno values are system specific (posix/linux/bare 
metal/?). The mechanism is portable (read/zero/print ODP errno), values are 
not. If user needs to include a system errno header by himself, that fact is 
highlighted.

As we are not (yet) specifying a portable range of errnos, so user can more or 
less log/report the value and not make a decision based on it.

-Petri


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

Re: [lng-odp] [PATCH v2 4/4] api: move loging out of odp_debug

[Savolainen, Petri (NSN - FI/Espoo)]

Reviewed-by: Petri Savolainen 


> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Mike Holmes
> Sent: Wednesday, January 21, 2015 1:38 AM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCH v2 4/4] api: move loging out of odp_debug
> 
> Only odp_init needs the logging definitions so remove them from
> odp_debug.h
> 
> Signed-off-by: Mike Holmes 
> ---
>  platform/linux-generic/include/api/odp_debug.h | 32 
>  platform/linux-generic/include/api/odp_init.h  | 41
> +-
>  platform/linux-generic/include/odp_internal.h  |  2 +-
>  3 files changed, 41 insertions(+), 34 deletions(-)
> 
> diff --git a/platform/linux-generic/include/api/odp_debug.h
> b/platform/linux-generic/include/api/odp_debug.h
> index 4c32500..ce07e85 100644
> --- a/platform/linux-generic/include/api/odp_debug.h
> +++ b/platform/linux-generic/include/api/odp_debug.h
> @@ -48,38 +48,6 @@ extern "C" {
>  #define _ODP_STATIC_ASSERT(cond, msg)  _Static_assert(cond, msg)
> 
>  /**
> - * ODP log level.
> - */
> -typedef enum odp_log_level {
> - ODP_LOG_DBG,
> - ODP_LOG_ERR,
> - ODP_LOG_UNIMPLEMENTED,
> - ODP_LOG_ABORT,
> - ODP_LOG_PRINT
> -} odp_log_level_e;
> -
> -/**
> - * ODP log function
> - *
> - * Instead of direct prints to stdout/stderr all logging in ODP
> implementation
> - * should be done via this function or its wrappers.
> - * ODP platform MUST provide a default *weak* implementation of this
> function.
> - * Application MAY override the function if needed by providing a strong
> - * function.
> - *
> - * @param[in] level   Log level
> - * @param[in] fmt printf-style message format
> - *
> - * @return The number of characters logged if succeeded. Otherwise
> returns
> - * a negative number.
> - */
> -extern int odp_override_log(odp_log_level_e level, const char *fmt, ...);
> -
> -
> -/** Replaceable logging function */
> -typedef int (*odp_log_func_t)(odp_log_level_e level, const char *fmt,
> ...);
> -
> -/**
>   * @}
>   */
> 
> diff --git a/platform/linux-generic/include/api/odp_init.h
> b/platform/linux-generic/include/api/odp_init.h
> index 73c4a3b..ac856df 100644
> --- a/platform/linux-generic/include/api/odp_init.h
> +++ b/platform/linux-generic/include/api/odp_init.h
> @@ -29,13 +29,52 @@ extern "C" {
> 
> 
>  #include 
> -#include 
> 
>  /** @defgroup odp_initialization ODP INITIALIZATION
>   *  Initialisation operations.
>   *  @{
>   */
> 
> +/**
> + * ODP log level.
> + */
> +typedef enum odp_log_level {
> + ODP_LOG_DBG,
> + ODP_LOG_ERR,
> + ODP_LOG_UNIMPLEMENTED,
> + ODP_LOG_ABORT,
> + ODP_LOG_PRINT
> +} odp_log_level_e;
> +
> +/**
> + * ODP log function
> + *
> + * Instead of direct prints to stdout/stderr all logging in an ODP
> + * implementation should be done via this function or its wrappers.
> + *
> + * The application can provide this function to the ODP implementation in
> two
> + * ways:
> + *
> + * - A callback passed in via in odp_init_t and odp_init_global()
> + * - By overriding the ODP implementation default log function
> + * odp_override_log().
> + *
> + * @warning The latter option is less portable and GNU linker dependent
> + * (utilizes function attribute "weak"). If both are defined, the
> odp_init_t
> + * function pointer has priority over the override function.
> + *
> + * @param[in] level   Log level
> + * @param[in] fmt printf-style message format
> + *
> + * @return The number of characters logged if succeeded. Otherwise
> returns
> + * a negative number.
> + */
> +int odp_override_log(odp_log_level_e level, const char *fmt, ...);
> +
> +
> +/** Replaceable logging function */
> +typedef int (*odp_log_func_t)(odp_log_level_e level, const char *fmt,
> ...);
> +
>  /** ODP initialization data.
>   * Data that is required to initialize the ODP API with the
>   * application specific data such as specifying a logging callback, the
> log
> diff --git a/platform/linux-generic/include/odp_internal.h
> b/platform/linux-generic/include/odp_internal.h
> index 7401a30..07c9f60 100644
> --- a/platform/linux-generic/include/odp_internal.h
> +++ b/platform/linux-generic/include/odp_internal.h
> @@ -18,7 +18,7 @@
>  extern "C" {
>  #endif
> 
> -#include 
> +#include 
> 
>  struct odp_global_data {
>   odp_log_func_t log_fn;
> --
> 2.1.0
> 
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp

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

Re: [lng-odp] [PATCH v2 06/16] api: buffer: Removed odp_buffer_type

[Savolainen, Petri (NSN - FI/Espoo)]

Thanks. I'll fix that tomorrow.

-Petri


> -Original Message-
> From: ext Maxim Uvarov [mailto:maxim.uva...@linaro.org]
> Sent: Tuesday, January 20, 2015 4:42 PM
> To: lng-odp@lists.linaro.org; Petri Savolainen
> Subject: Re: [lng-odp] [PATCH v2 06/16] api: buffer: Removed
> odp_buffer_type
> 
> Petri, you just did mistake in test.
> 
> 
> test/validation/buffer/odp_buffer_pool_test.c
> pool_alloc_type()
> 
> 
> case ODP_BUFFER_TYPE_RAW:
>  buf = alloc_buf;
> case ODP_BUFFER_TYPE_PKT:
> packet = alloc_packet;
> 
> 
> 
> Then you calll free for both buf and packet. But in one case you did not
> allocate packet,
> in other case you did not allocate buffer.
> 
> Maxim.
> 
> On 01/20/2015 05:29 PM, Maxim Uvarov wrote:
> > Core was generated by `./odp_buffer'.
> > Program terminated with signal 11, Segmentation fault.
> > #0  0x00406614 in odp_buf_to_pool (buf=0x134a1300) at
> > ./include/odp_buffer_pool_internal.h:358
> > 358return odp_pool_to_entry(buf->pool_hdl);
> > (gdb) bt
> > #0  0x00406614 in odp_buf_to_pool (buf=0x134a1300) at
> > ./include/odp_buffer_pool_internal.h:358
> > #1  0x00407964 in odp_buffer_free (buf=2187936352) at
> > odp_buffer_pool.c:518
> > #2  0x00409666 in odp_packet_free (pkt=2187936352) at
> > odp_packet.c:52
> > #3  0x0040256e in pool_alloc_type (type=1) at
> > buffer/odp_buffer_pool_test.c:171
> > #4  0x004025c3 in pool_alloc_buffer_raw () at
> > buffer/odp_buffer_pool_test.c:179
> > #5  0x7f81826a1f06 in run_single_test (pTest=0x191e0d0,
> > pRunSummary=0x7f81828ab4c0) at TestRun.c:991
> > #6  0x7f81826a1b3c in run_single_suite (pSuite=0x191c280,
> > pRunSummary=0x7f81828ab4c0) at TestRun.c:876
> > #7  0x7f818269f98b in CU_run_all_tests () at TestRun.c:367
> > #8  0x7f81826a3e7d in basic_run_all_tests (pRegistry=0x0) at
> > Basic.c:195
> > #9  0x7f81826a3c1a in CU_basic_run_tests () at Basic.c:87
> > #10 0x0040592a in main () at common/odp_cunit_common.c:72
> > (gdb) p *buf
> > Cannot access memory at address 0x134a1300
> > (gdb) l
> > 353return (pool_entry_t
> > *)get_pool_entry(pool_handle_to_index(pool));
> > 354}
> > 355
> > 356static inline pool_entry_t *odp_buf_to_pool(odp_buffer_hdr_t
> *buf)
> > 357{
> > 358return odp_pool_to_entry(buf->pool_hdl);
> > 359}
> > 360
> > 361static inline uint32_t
> > odp_buffer_pool_segment_size(odp_buffer_pool_t pool)
> > 362{
> > (gdb)
> >
> > On 01/20/2015 02:18 PM, Petri Savolainen wrote:
> >> Removed odp_buffer_type() from API and made it internal.
> >>
> >> Signed-off-by: Petri Savolainen 
> >> ---
> >>   platform/linux-generic/include/api/odp_buffer.h| 16 
> >>   .../linux-generic/include/api/odp_buffer_pool.h|  4 +
> >>   .../linux-generic/include/odp_buffer_internal.h| 16 
> >>   platform/linux-generic/odp_buffer.c|  2 +-
> >>   platform/linux-generic/odp_buffer_pool.c   |  4 +-
> >>   platform/linux-generic/odp_event.c |  4 +-
> >>   platform/linux-generic/odp_timer.c |  4 +-
> >>   test/validation/buffer/odp_buffer_pool_test.c  | 88
> >> +-
> >>   test/validation/buffer/odp_buffer_test.c   |  4 +-
> >>   test/validation/buffer/odp_packet_test.c   | 15 ++--
> >>   test/validation/odp_pktio.c| 16 ++--
> >>   test/validation/odp_timer.c|  2 +-
> >>   12 files changed, 97 insertions(+), 78 deletions(-)
> >>
> >> diff --git a/platform/linux-generic/include/api/odp_buffer.h
> >> b/platform/linux-generic/include/api/odp_buffer.h
> >> index 5f825a2..69d5779 100644
> >> --- a/platform/linux-generic/include/api/odp_buffer.h
> >> +++ b/platform/linux-generic/include/api/odp_buffer.h
> >> @@ -69,22 +69,6 @@ void *odp_buffer_addr(odp_buffer_t buf);
> >>   uint32_t odp_buffer_size(odp_buffer_t buf);
> >> /**
> >> - * Buffer type
> >> - *
> >> - * @param buf  Buffer handle
> >> - *
> >> - * @return Buffer type
> >> - */
> >> -int odp_buffer_type(odp_buffer_t buf);
> >> -
> >> -#define ODP_BUFFER_TYPE_INVALID (-1) /**< Buffer type invalid */
> >> -#define ODP_BUFFER_TYPE_ANY   0  /**< Buffer that can hold any
> >> other
> >> -  buffer type */
> >> -#define ODP_BUFFER_TYPE_RAW   1  /**< Raw buffer, no additional
> >> metadata */
> >> -#define ODP_BUFFER_TYPE_PACKET2  /**< Packet buffer */
> >> -#define ODP_BUFFER_TYPE_TIMEOUT   3  /**< Timeout buffer */
> >> -
> >> -/**
> >>* Tests if buffer is valid
> >>*
> >>* @param buf  Buffer handle
> >> diff --git a/platform/linux-generic/include/api/odp_buffer_pool.h
> >> b/platform/linux-generic/include/api/odp_buffer_pool.h
> >> index 8380ac1..68fa69e 100644
> >> --- a/platform/linux-generic/include/api/odp_buffer_pool.h
> >> +++ b/platform/linux-generic/include/api/odp_buffer_pool.h
> >> @@ -51,6 +51,10 @@ typedef struct odp_buffer_pool_

Re: [lng-odp] [PATCH v2 00/16] Event introduction

[Savolainen, Petri (NSN - FI/Espoo)]

In my system “make check” seg faults (in odp_init, etc) already with the 
current code from the repo.

-Petri

From: ext Mike Holmes [mailto:mike.hol...@linaro.org]
Sent: Tuesday, January 20, 2015 3:13 PM
To: Petri Savolainen
Cc: lng-odp
Subject: Re: [lng-odp] [PATCH v2 00/16] Event introduction


On 20 January 2015 at 06:17, Petri Savolainen 
mailto:petri.savolai...@linaro.org>> wrote:
This patch set introduces odp_event_t. It replaces odp_buffer_t in many places
with odp_event_t. Events are the objects that are transimitted by and scheduled
from queues. Event is the new "super class" for various events (buffers,
packets, timeouts, etc). Various event types can be converted to odp_event_t
(and back), but not to another event type.

Buffer pool is also changed to a generic "pool". Pool and event types have
been separated. There are matching pool types for buffer, packet and timeout
events (as "buffer types" before). Later on, there can be event types without
a matching pool type, and pool types without a matching event type.

Some lines are over 80 chars. Those are mainly caused by temporary
event <-> buffer, packet -> event -> buffer conversions and should be cleaned up
from the implementation. This patch set does minimal implementation changes.

It is not unreadable to have these changes checkpatch clean,  one line that 
moved to two is very understandable.

Also running these patches  with "make check" after applying each one results 
in failures along the way.
Starting fresh and applying all the patches at once and running make check gives


PASS: odp_init
PASS: odp_queue
../../test-driver: line 107: 18152 Segmentation fault  (core dumped) "$@" > 
$log_file 2>&1
FAIL: odp_crypto
PASS: odp_shm
PASS: odp_schedule
PASS: odp_pktio_run
../../test-driver: line 107: 21042 Segmentation fault  (core dumped) "$@" > 
$log_file 2>&1
FAIL: odp_buffer
PASS: odp_system
FAIL: odp_timer
PASS: odp_time
PASS: odp_synchronizers
make[5]: Entering directory '/home/mike/git/odp/test/validation'
make[5]: Nothing to be done for 'all'.
make[5]: Leaving directory '/home/mike/git/odp/test/validation'

Testsuite summary for OpenDataPlane 0.8.0

# TOTAL: 11
# PASS:  8
# SKIP:  0
# XFAIL: 0
# FAIL:  3
# XPASS: 0
# ERROR: 0

See test/validation/test-suite.log
Please report to lng-odp@lists.linaro.org


NB timer is sustable to failure until we get Olas latest code in.



Petri Savolainen (16):
  api: event: Add odp_event_t
  api: event: odp_schedule and odp_queue_enq
  api: event: schedule_multi and queue_enq_multi
  api: event: odp_queue_deq
  api: event: odp_queue_deq_multi
  api: buffer: Removed odp_buffer_type
  api: packet: Removed odp_packet_to_buffer
  api: packet: Removed odp_packet_from_buffer
  api: timer: Use odp_event_t instead of odp_buffer_t
  api: crypto: Use odp_event_t instead of odp_buffer_t
  linux-generic: crypto: Use packet alloc for packet
  api: buffer_pool: Rename odp_buffer_pool.h to odp_pool.h
  api: pool: Rename pool params and remove buffer types
  api: pool: Rename odp_buffer_pool_ to odp_pool_
  api: config: Renamed ODP_CONFIG_BUFFER_POOLS
  api: timer: Added timeout alloc and free

 example/generator/odp_generator.c  |  38 ++--
 example/ipsec/odp_ipsec.c  |  70 +++
 example/ipsec/odp_ipsec_cache.c|   4 +-
 example/ipsec/odp_ipsec_cache.h|   2 +-
 example/ipsec/odp_ipsec_loop_db.c  |   2 +-
 example/ipsec/odp_ipsec_loop_db.h  |  12 +-
 example/ipsec/odp_ipsec_stream.c   |  20 +-
 example/ipsec/odp_ipsec_stream.h   |   2 +-
 example/l2fwd/odp_l2fwd.c  |  28 +--
 example/packet/odp_pktio.c |  28 +--
 example/timer/odp_timer_test.c |  74 
 platform/linux-generic/Makefile.am |   4 +-
 platform/linux-generic/include/api/odp.h   |   3 +-
 platform/linux-generic/include/api/odp_buffer.h|  40 ++--
 .../linux-generic/include/api/odp_buffer_pool.h| 177 --
 .../linux-generic/include/api/odp_classification.h |   2 +-
 platform/linux-generic/include/api/odp_config.h|   4 +-
 platform/linux-generic/include/api/odp_crypto.h|  16 +-
 platform/linux-generic/include/api/odp_event.h |  59 ++
 platform/linux-generic/include/api/odp_packet.h|  29 +--
 platform/linux-generic/include/api/odp_packet_io.h |   4 +-
 .../linux-generic/include/api/odp_platform_types.h |  10 +-
 platform/linux-generic/include/api/odp_pool.h  | 202 +
 platform/linux-generic/include/api/odp_queue.h |  32 ++--
 platform/linux-generic/include/api/odp_schedule.h  |  32 ++--
 pl

Re: [lng-odp] [PATCHv2] linux-generic: Add odp_errno and adapt packet_io and timer implementations to use it

[Savolainen, Petri (NSN - FI/Espoo)]

> --- /dev/null
> +++ b/platform/linux-generic/include/api/odp_errno.h
> @@ -0,0 +1,61 @@
> +/* Copyright (c) 2015, Linaro Limited
> + * All rights reserved.
> + *
> + * SPDX-License-Identifier:  BSD-3-Clause
> + */
> +
> +/**
> + * @file
> + *
> + * ODP errno API
> + */
> +
> +#ifndef ODP_ERRNO_H_
> +#define ODP_ERRNO_H_
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#include 

This should be removed from API file (only implementation needs it).

> +
> +/**
> +* Return latest ODP errno
> +*
> +* @retval 0 == no error

@return ODP errno
@retval 0 No error

It's likely that "==" would not look good on Doxygen doc. It's from my mail, 
sorry about that.

-Petri

> +*/
> +int odp_errno(void);
> +

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

Re: [lng-odp] [PATCH 4/4] api: move loging out of odp_debug

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Mike Holmes
> Sent: Monday, January 19, 2015 3:56 AM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCH 4/4] api: move loging out of odp_debug
> 
> Only odp_init needs the logging definitions so remove them from
> odp_debug.h
> 
> Signed-off-by: Mike Holmes 
> ---
>  platform/linux-generic/include/api/odp_debug.h | 32 -
> --
>  platform/linux-generic/include/api/odp_init.h  | 36
> +-
>  platform/linux-generic/include/odp_internal.h  |  2 +-
>  3 files changed, 36 insertions(+), 34 deletions(-)
> 
> diff --git a/platform/linux-generic/include/api/odp_debug.h
> b/platform/linux-generic/include/api/odp_debug.h
> index 4c32500..ce07e85 100644
> --- a/platform/linux-generic/include/api/odp_debug.h
> +++ b/platform/linux-generic/include/api/odp_debug.h
> @@ -48,38 +48,6 @@ extern "C" {
>  #define _ODP_STATIC_ASSERT(cond, msg)  _Static_assert(cond, msg)
> 
>  /**
> - * ODP log level.
> - */
> -typedef enum odp_log_level {
> - ODP_LOG_DBG,
> - ODP_LOG_ERR,
> - ODP_LOG_UNIMPLEMENTED,
> - ODP_LOG_ABORT,
> - ODP_LOG_PRINT
> -} odp_log_level_e;
> -
> -/**
> - * ODP log function
> - *
> - * Instead of direct prints to stdout/stderr all logging in ODP
> implementation
> - * should be done via this function or its wrappers.
> - * ODP platform MUST provide a default *weak* implementation of this
> function.
> - * Application MAY override the function if needed by providing a strong
> - * function.
> - *
> - * @param[in] level   Log level
> - * @param[in] fmt printf-style message format
> - *
> - * @return The number of characters logged if succeeded. Otherwise
> returns
> - * a negative number.
> - */
> -extern int odp_override_log(odp_log_level_e level, const char *fmt, ...);
> -
> -
> -/** Replaceable logging function */
> -typedef int (*odp_log_func_t)(odp_log_level_e level, const char *fmt,
> ...);
> -
> -/**
>   * @}
>   */
> 
> diff --git a/platform/linux-generic/include/api/odp_init.h
> b/platform/linux-generic/include/api/odp_init.h
> index 73c4a3b..b0ea316 100644
> --- a/platform/linux-generic/include/api/odp_init.h
> +++ b/platform/linux-generic/include/api/odp_init.h
> @@ -29,13 +29,47 @@ extern "C" {
> 
> 
>  #include 
> -#include 
> 
>  /** @defgroup odp_initialization ODP INITIALIZATION
>   *  Initialisation operations.
>   *  @{
>   */
> 
> +/**
> + * ODP log level.
> + */
> +typedef enum odp_log_level {
> + ODP_LOG_DBG,
> + ODP_LOG_ERR,
> + ODP_LOG_UNIMPLEMENTED,
> + ODP_LOG_ABORT,
> + ODP_LOG_PRINT
> +} odp_log_level_e;
> +
> +/**
> + * ODP log function
> + *
> + * Instead of direct prints to stdout/stderr all logging in ODP
> implementation
> + * should be done via this function or its wrappers.

I think the callback and weak methods should be documented better, something 
like this:

"User can provide this function to the ODP implementation in two ways: as
a callback in odp_init_t or by overriding the ODP implementation default log
function (odp_override_log()). The latter option is less portable and GNU linker
dependent (utilizes function attribute "weak"). If both are defined, the
odp_init_t function pointer has priority over the override function."


> + * ODP platform MUST provide a default *weak* implementation of this
> function.
> + * Application MAY override the function if needed by providing a strong
> + * function.

... and maybe these notes can be removed then.

> + *
> + * @warning The use of the weak replacement is not as portable as using
> the
> + * odp_init_global() function parmiters.

Typo: "parameters"


-Petri


> + *
> + * @param[in] level   Log level
> + * @param[in] fmt printf-style message format
> + *
> + * @return The number of characters logged if succeeded. Otherwise
> returns
> + * a negative number.
> + */
> +int odp_override_log(odp_log_level_e level, const char *fmt, ...);
> +
> +
> +/** Replaceable logging function */
> +typedef int (*odp_log_func_t)(odp_log_level_e level, const char *fmt,
> ...);
> +
>  /** ODP initialization data.
>   * Data that is required to initialize the ODP API with the
>   * application specific data such as specifying a logging callback, the
> log
> diff --git a/platform/linux-generic/include/odp_internal.h
> b/platform/linux-generic/include/odp_internal.h
> index 7401a30..07c9f60 100644
> --- a/platform/linux-generic/include/odp_internal.h
> +++ b/platform/linux-generic/include/odp_internal.h
> @@ -18,7 +18,7 @@
>  extern "C" {
>  #endif
> 
> -#include 
> +#include 
> 
>  struct odp_global_data {
>   odp_log_func_t log_fn;
> --
> 2.1.0
> 
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp

___
lng-odp mailing list
lng-odp@lists.linaro.org
http://lis

Re: [lng-odp] Regarding odp_packet_t and buffer chaining

[Savolainen, Petri (NSN - FI/Espoo)]

Hi,

Packet chaining and segment manipulation functions will be added later on this 
year.

Currently, copying is the only way to combine data from two packets. Either add 
data space into pkt1 (odp_packet_add_data()) and copy data from pkt2, or 
allocate pkt3 and copy data from pkt1 and pkt2.

-Petri



From: lng-odp-boun...@lists.linaro.org 
[mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of ext Prashant Upadhyaya
Sent: Tuesday, January 20, 2015 7:28 AM
To: lng-odp@lists.linaro.org
Subject: [lng-odp] Regarding odp_packet_t and buffer chaining

Hi,

Suppose I have pkt1 and pk2 which are instances of odp_packet_t.
Now I have two questions -


1.  what is the way to chain the buffers of pkt1 and pkt2 into pkt1 so that 
from now on I can just use pkt1 for transmission via, say, odp_pktio_send API

2.  if I create a new odp_packet_t pkt3, then how can I take buffers out of 
pkt1 and pk2 and chain them up in pkt3 so that I can send pkt3 via 
odp_pktio_send API

We can assume that all pkt's are obtained from the same buffer pool.
If there is a way to chain up pkt's themselves instead of the buffers 
associated with them, that is also ok by me.

Unfortunately I am not clear regarding the API calls to be used at the 
application level for this, that is the guidance I am looking for - what is the 
official way in an ODP compliant application to achieve the above usecases.

The ultimate idea ofcourse is to chain up the packets/buffers so that I can 
avoid mem copies to create a single buffer to be sent out. (something similar 
to 'mbuf chaining' supported by eg. DPDK)

Regards
-Prashant

"DISCLAIMER: This message is proprietary to Aricent and is intended solely for 
the use of the individual to whom it is addressed. It may contain privileged or 
confidential information and should not be circulated or used for any purpose 
other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended 
recipient, you are notified that you are strictly prohibited from using, 
copying, altering, or disclosing the contents of this message. Aricent accepts 
no responsibility for loss or damage arising from the use of the information 
transmitted by this email including damage from virus."
___
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp

Re: [lng-odp] [PATCH 00/15] Event introduction

[Savolainen, Petri (NSN - FI/Espoo)]

> 
> No, I was considering the abstraction for the fixed size buffer pool only.
> The new type can used to allocate a buffer pool from hardware fixed size
> buffer manager
> without any metadata for queueable. something like,
> 
> pool = odp_buffer_pool_create();
> odp_buffer_t x = odp_buffer_alloc(pool); // for queueable buffers
> 
> odp_buffer_xxx_t x = odp_buffer_xxx_alloc(pool);// for non queueable
> buffers, only for storage


This can be defined after v1.0. I already separated event (ODP_EVENT_XXX) and 
pool type (ODP_POOL_XXX) defines for rev2 of the event patch. With that, there 
can be event types that do not have a matching pool type (no pool, no alloc 
call), and pool types that do not have a matching event type (no xxx_to_event 
call => no queues, no scheduling).

-Petri 

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

Re: [lng-odp] [PATCH 00/15] Event introduction

[Savolainen, Petri (NSN - FI/Espoo)]

Maybe it’s better to test first which way results less (and more trivial) merge 
conflicts. I suspect that event first, directory/file restructure second would 
be easier job for git merge tool.

Once we have decide that events are the way to go, someone can pick-up the job 
to update validation suite. It’s just matter of optimizing work flow for next 
couple of weeks.

-Petri


From: ext Bill Fischofer [mailto:bill.fischo...@linaro.org]
Sent: Friday, January 16, 2015 1:13 PM
To: Savolainen, Petri (NSN - FI/Espoo)
Cc: ext Ola Liljedahl; LNG ODP Mailman List
Subject: Re: [lng-odp] [PATCH 00/15] Event introduction

We definitely need the validation tests to be updated as part of the initial 
patch, otherwise we have a patch that results in a non-buildable system, which 
violates our agreed-to patch rules.

Given that Anders' API restructure patch is at a more complete state and is 
needed to support API inlining in a portable manner, I suggest that we 
integrate that patch first and then rebase this one (in a complete form) on it. 
 This would also ease the conversion issues for other implementations since 
this change would then ride on the platform-independent API structure that the 
former patch introduces.

On Fri, Jan 16, 2015 at 4:52 AM, Savolainen, Petri (NSN - FI/Espoo) 
mailto:petri.savolai...@nsn.com>> wrote:
Yes, agree validation needs to be updated (soon or at the same time).

Because the patch set is out now, someone could have picked that up and started 
that work already yesterday. We just need to decide if we merge this for 0.9 
and if so, who updates validation suite and how those are merged. This patch 
set builds and runs for the default target.

./bootstrap
./configure
make


-Petri


> -Original Message-
> From: ext Ola Liljedahl 
> [mailto:ola.liljed...@linaro.org<mailto:ola.liljed...@linaro.org>]
> Sent: Friday, January 16, 2015 12:43 PM
> To: Savolainen, Petri (NSN - FI/Espoo)
> Cc: ext Bill Fischofer; LNG ODP Mailman List
> Subject: Re: [lng-odp] [PATCH 00/15] Event introduction
>
> Petri this is quite well described but really should be part of the
> patch description (in the cover letter)? Then no need to have to ask
> why all this is done.
> I think we would like the validation suite (and everything else) to
> build as well... It's a bitch to change API's, I know.
> Even if the changes in some (more or less subjective) ways are not
> complete, if everything builds and runs then we know that ODP is in
> the same state as before the patch was applied. Cleaning up the
> implementation can and will always continue.
>
>
> On 16 January 2015 at 10:25, Savolainen, Petri (NSN - FI/Espoo)
> mailto:petri.savolai...@nsn.com>> wrote:
> >
> >
> >
> >
> > From: ext Bill Fischofer 
> > [mailto:bill.fischo...@linaro.org<mailto:bill.fischo...@linaro.org>]
> > Sent: Thursday, January 15, 2015 11:26 PM
> > To: Petri Savolainen
> > Cc: LNG ODP Mailman List
> > Subject: Re: [lng-odp] [PATCH 00/15] Event introduction
> >
> >
> >
> > Some more observations after having looked this over in a bit more
> detail:
> >
> >
> >
> > This patch in its current form is basically a massive rename from
> buffers to
> > events and changing things like odp_buffer_pool_t to odp_pool_t.
> Presumably
> > this is intended to be followed by additional patches that surface new
> > capabilities that build on this revised nomenclature, but for now the
> > advantages of this change are unclear.  While a patch is good, it would
> be
> > really helpful to have a description of what the envisioned target looks
> > like so that the motivation behind this rename can be better
> appreciated.
> >
> >
> >
> > This patch set introduces the new API structure. Implementation changes
> are
> > minimal since it’s an implementation choice if buffer is used as the
> base
> > class. Validation should be added and implementation cleaned where
> needed
> > after this.
> >
> >
> >
> > As we have talked this already multiple times:
> >
> > -Event replaces buffer as the “base class” of things that can be
> > transmitted over queues and scheduled
> >
> > -Event has minimum metadata (only event type ==
> odp_event_type())
> >
> > -Currently supported event types are: buffer, packet, timeout.
> > Crypto completion event is likely to be the fourth one.
> >
> > -Buffer is just a another event (=raw buffer, no segmentation)
> >
> > -Benefit of the opaque base class is that different event types
> are
> > more independent (e.g. do not have to implement odp_buffer_size(),
> > odp_buffer_a

Re: [lng-odp] [PATCHv1 1/3] api: crypto: new completion event scheme

[Savolainen, Petri (NSN - FI/Espoo)]

Speculating that this will be rebased after event patch...



Compl event type definition:

odp_event.h
/**< Invalid event type */
#define ODP_EVENT_TYPE_INVALID (-1)
/**< Packet event */
#define ODP_EVENT_PACKET   (ODP_EVENT_TYPE_INVALID + 1)
/**< Buffer event */
#define ODP_EVENT_BUFFER   (ODP_EVENT_TYPE_INVALID + 2)
/**< Timeout event */
#define ODP_EVENT_TIMEOUT  (ODP_EVENT_TYPE_INVALID + 3)
+ /**< Crypto completion event */
+ #define ODP_EVENT_CRYPTO_COMPL (ODP_EVENT_TYPE_INVALID + 4)



> 
> diff --git a/platform/linux-generic/include/api/odp_crypto.h
> b/platform/linux-generic/include/api/odp_crypto.h
> index 337e7cf..3815dee 100644
> --- a/platform/linux-generic/include/api/odp_crypto.h
> +++ b/platform/linux-generic/include/api/odp_crypto.h
> @@ -141,6 +141,7 @@ typedef struct odp_crypto_session_params {
>   */
>  typedef struct odp_crypto_op_params {
>   odp_crypto_session_t session;   /**< Session handle from creation */
> + void *ctx;  /**< User context */
>   odp_packet_t pkt;   /**< Input packet buffer */
>   odp_packet_t out_pkt;   /**< Output packet buffer */
>   uint8_t *override_iv_ptr;   /**< Override session IV pointer */
> @@ -210,6 +211,21 @@ typedef struct odp_crypto_compl_status {
>   enum crypto_hw_err  hw_err;   /**< Hardware specific return code */
>  } odp_crypto_compl_status_t;
> 
> +/**
> + * Cryto API completion event
> + */
> +typedef odp_buffer_t odp_crypto_compl_event_t;

"Event" can be dropped from the type name
typedef odp_buffer_t odp_crypto_compl_t;


> +
> +/**
> + * Crypto API operation result
> + */
> +typedef struct odp_crypto_op_result {
> + odp_bool_t  ok;  /**< Request completed successfully
> */
> + void *ctx;   /**< User context from request */
> + odp_packet_t pkt;/**< Output packet */
> + odp_crypto_compl_status_t cipher_status; /**< Cipher status */
> + odp_crypto_compl_status_t auth_status;   /**< Authentication status
> */
> +} odp_crypto_op_result_t;
> 
>  /**
>   * Crypto session creation (synchronous)
> @@ -225,76 +241,53 @@
> odp_crypto_session_create(odp_crypto_session_params_t *params,
> odp_crypto_session_t *session,
> enum odp_crypto_ses_create_err *status);
> 
> +/**
> + * Release crypto completion event
> + *
> + * @param completion_event  Completion event we are done accessing
> + */
> +void
> +odp_crypto_release_compl_event(odp_crypto_compl_event_t
> completion_event);

Shorter and buffer_free/packet_free compatible name?

void odp_crypto_compl_free(odp_crypto_compl_t compl);


> +
> +/**
> + * Convert buffer to completion event
> + *
> + * @param buffer   Generic ODP buffer
> + *
> + * @return Completion event
> + */
> +odp_crypto_compl_event_t
> +odp_crypto_compl_event_from_buffer(odp_buffer_t buffer);

>From event to compl. Drop "event" from names.

odp_crypto_compl_t odp_crypto_compl_from_event(odp_event_t event);


> 
>  /**
>   * Crypto per packet operation
>   *
>   * Performs the cryptographic operations specified during session
> creation
>   * on the packet.  If the operation is performed synchronously, "posted"
> - * will return FALSE and the result of the operation is immediately
> available
> - * in the completion event.  If "posted" returns TRUE the result will be
> - * delivered via the completion queue specified when the session was
> created.
> - *
> - * @todo Resolve if completion_event is necessary, can/should the output
> - *   packet buffer always be used instead.
> + * will return FALSE and the result of the operation is immediately
> available.
> + * If "posted" returns TRUE the result will be delivered via the
> completion
> + * queue specified when the session was created.
>   *
>   * @param paramsOperation parameters
>   * @param postedPointer to return posted, TRUE for async
> operation
> - * @param completion_event  Event by which the operation results are
> delivered.
> + * @param resultResults of operation (when posted returns
> FALSE)
>   *
>   * @return 0 if successful else -1
>   */
>  int
>  odp_crypto_operation(odp_crypto_op_params_t *params,
>bool *posted,
> -  odp_buffer_t completion_event);
> +  odp_crypto_op_result_t *result);
> 
>  /**
> - * Crypto per packet operation set user context in completion event
> + * Crypto per packet operation query result from completion event
>   *
>   * @param completion_event  Event containing operation results
> - * @param ctx   User data
> + * @param resultPointer to result structure
>   */
>  void
> -odp_crypto_set_operation_compl_ctx(odp_buffer_t completion_event,
> -void *ctx);
> -
> -/**
> - * Crypto per packet operation completion status
> - *
> - * Accessor function for obtaining operation status from the completion

Re: [lng-odp] [PATCH 00/15] Event introduction

[Savolainen, Petri (NSN - FI/Espoo)]

Yes, agree validation needs to be updated (soon or at the same time).

Because the patch set is out now, someone could have picked that up and started 
that work already yesterday. We just need to decide if we merge this for 0.9 
and if so, who updates validation suite and how those are merged. This patch 
set builds and runs for the default target.

./bootstrap
./configure
make


-Petri


> -Original Message-
> From: ext Ola Liljedahl [mailto:ola.liljed...@linaro.org]
> Sent: Friday, January 16, 2015 12:43 PM
> To: Savolainen, Petri (NSN - FI/Espoo)
> Cc: ext Bill Fischofer; LNG ODP Mailman List
> Subject: Re: [lng-odp] [PATCH 00/15] Event introduction
> 
> Petri this is quite well described but really should be part of the
> patch description (in the cover letter)? Then no need to have to ask
> why all this is done.
> I think we would like the validation suite (and everything else) to
> build as well... It's a bitch to change API's, I know.
> Even if the changes in some (more or less subjective) ways are not
> complete, if everything builds and runs then we know that ODP is in
> the same state as before the patch was applied. Cleaning up the
> implementation can and will always continue.
> 
> 
> On 16 January 2015 at 10:25, Savolainen, Petri (NSN - FI/Espoo)
>  wrote:
> >
> >
> >
> >
> > From: ext Bill Fischofer [mailto:bill.fischo...@linaro.org]
> > Sent: Thursday, January 15, 2015 11:26 PM
> > To: Petri Savolainen
> > Cc: LNG ODP Mailman List
> > Subject: Re: [lng-odp] [PATCH 00/15] Event introduction
> >
> >
> >
> > Some more observations after having looked this over in a bit more
> detail:
> >
> >
> >
> > This patch in its current form is basically a massive rename from
> buffers to
> > events and changing things like odp_buffer_pool_t to odp_pool_t.
> Presumably
> > this is intended to be followed by additional patches that surface new
> > capabilities that build on this revised nomenclature, but for now the
> > advantages of this change are unclear.  While a patch is good, it would
> be
> > really helpful to have a description of what the envisioned target looks
> > like so that the motivation behind this rename can be better
> appreciated.
> >
> >
> >
> > This patch set introduces the new API structure. Implementation changes
> are
> > minimal since it’s an implementation choice if buffer is used as the
> base
> > class. Validation should be added and implementation cleaned where
> needed
> > after this.
> >
> >
> >
> > As we have talked this already multiple times:
> >
> > -Event replaces buffer as the “base class” of things that can be
> > transmitted over queues and scheduled
> >
> > -Event has minimum metadata (only event type ==
> odp_event_type())
> >
> > -Currently supported event types are: buffer, packet, timeout.
> > Crypto completion event is likely to be the fourth one.
> >
> > -Buffer is just a another event (=raw buffer, no segmentation)
> >
> > -Benefit of the opaque base class is that different event types
> are
> > more independent (e.g. do not have to implement odp_buffer_size(),
> > odp_buffer_addr(), etc)
> >
> > -There are event types that do not carry data, but only metadata
> > (e.g. timer timeout). Also in future, some event types may not be linked
> to
> > a pool (user could not allocate, or ask for the pool)
> >
> > -Application cannot access one event type through multiple APIs
> > (e.g. mix odp_buffer_xxx() and odp_packet_xxx() calls when accessing a
> > packet)
> >
> > -Pools are not only for buffers, but for multiple event types
> > (buffers, packets, timeouts, etc)
> >
> >
> >
> >
> >
> > Unless we also get API inline support into v1.0, there will be a
> performance
> > hit here since as a result of the rename it seems a lot of applications
> will
> > be making frequent calls to odp_buffer_to_event() and
> > odp_buffer_from_event() that were not needed before.
> >
> >
> >
> > Performance is exactly the same as earlier. There are same number of
> handle
> > conversions for packet, timeouts, etc (other than raw buffers). The
> > conversion is still most likely a cast. I added some extra conversion
> into
> > implementation to limit implementation changes (but performance of two
> type
> > casts instead of one is the same).
> >
> >
> >
> > ev = odp_schedule();
> >
> > pkt = odp_packet_from_e

Re: [lng-odp] [PATCH 00/15] Event introduction

[Savolainen, Petri (NSN - FI/Espoo)]

From: ext Bill Fischofer [mailto:bill.fischo...@linaro.org]
Sent: Thursday, January 15, 2015 11:26 PM
To: Petri Savolainen
Cc: LNG ODP Mailman List
Subject: Re: [lng-odp] [PATCH 00/15] Event introduction

Some more observations after having looked this over in a bit more detail:

This patch in its current form is basically a massive rename from buffers to 
events and changing things like odp_buffer_pool_t to odp_pool_t.  Presumably 
this is intended to be followed by additional patches that surface new 
capabilities that build on this revised nomenclature, but for now the 
advantages of this change are unclear.  While a patch is good, it would be 
really helpful to have a description of what the envisioned target looks like 
so that the motivation behind this rename can be better appreciated.

This patch set introduces the new API structure. Implementation changes are 
minimal since it’s an implementation choice if buffer is used as the base 
class. Validation should be added and implementation cleaned where needed after 
this.

As we have talked this already multiple times:

-Event replaces buffer as the “base class” of things that can be 
transmitted over queues and scheduled

-Event has minimum metadata (only event type == odp_event_type())

-Currently supported event types are: buffer, packet, timeout. Crypto 
completion event is likely to be the fourth one.

-Buffer is just a another event (=raw buffer, no segmentation)

-Benefit of the opaque base class is that different event types are 
more independent (e.g. do not have to implement odp_buffer_size(), 
odp_buffer_addr(), etc)

-There are event types that do not carry data, but only metadata (e.g. 
timer timeout). Also in future, some event types may not be linked to a pool 
(user could not allocate, or ask for the pool)

-Application cannot access one event type through multiple APIs (e.g. 
mix odp_buffer_xxx() and odp_packet_xxx() calls when accessing a packet)

-Pools are not only for buffers, but for multiple event types (buffers, 
packets, timeouts, etc)



Unless we also get API inline support into v1.0, there will be a performance 
hit here since as a result of the rename it seems a lot of applications will be 
making frequent calls to odp_buffer_to_event() and odp_buffer_from_event() that 
were not needed before.

Performance is exactly the same as earlier. There are same number of handle 
conversions for packet, timeouts, etc (other than raw buffers). The conversion 
is still most likely a cast. I added some extra conversion into implementation 
to limit implementation changes (but performance of two type casts instead of 
one is the same).

ev = odp_schedule();
pkt = odp_packet_from_event(ev)

vs.

buf = odp_schedule();
pkt = odp_packet_from_buffer(buf);


There are a few oddities.  Why wasn't odp_buffer_pool.c renamed to odp_pool.c 
since it now implements odp_pool_create(), not odp_buffer_pool_create(), etc.?  
There also doesn't appear to be any way to manipulate events other than by 
first converting them to buffers.  For example, when an event is obtained from 
odp_schedule() it can't be freed.  Instead, you do an odp_buffer_from_event() 
followed by an odp_buffer_free() call. This seems awkward.

Since .c is implementation. I did minimal implementation change. Others can 
continue with implementation clean ups where needed.

odp_event_free(odp_event_t* ev) can be added, but it would be mostly useful 
when application wants to blindly drop an event (without checking its type 
first).

Event <-> buffer conversion is the feature. It promotes usage of correct types 
when accessing the event. Also (linux-generic) implementation should enforce 
type correctness and report a build (or run time) error if user tries to e.g. 
do odp_buffer_addr(event) or odp_packet_data(buf).

The odp_pool_param_t (formerly odp_buffer_pool_param_t) is also incomplete 
since it's not clear how its intended to be used for the various event types.  
For example, there is a pkt section that has some items but odp_pool_create() 
still only references the buf section for creating packet events.  And the tmo 
section is null.

It’s incomplete to minimize implementation changes at this point. Those packet 
(and timeout) pool parametesr have to be defined and implementation changed 
accordingly. This type change enabled per event/pool type parameters, but does 
not implement those yet (== does not change the current pool param 
functionality).

It seems very late in v1.0 to be contemplating this large a change, especially 
as it doesn't seem to be fully fleshed out yet.  It would seem if we did 
something partial now applications would still face a step function conversion 
when the "second half" of the change was introduced later.  So I'm wondering if 
it might be better if this were deferred to post-v1.0 to allow time for it to 
be fully developed and introduced as part of a later release?  I think we 

Re: [lng-odp] [PATCH 00/15] Event introduction

[Savolainen, Petri (NSN - FI/Espoo)]

True, validation suites are not updated. Those can be updated after merge.

-Petri

From: ext Bill Fischofer [mailto:bill.fischo...@linaro.org]
Sent: Thursday, January 15, 2015 9:58 PM
To: Petri Savolainen
Cc: LNG ODP Mailman List
Subject: Re: [lng-odp] [PATCH 00/15] Event introduction

Actually, looks like none of the unit tests are updated by this patch, so 
tests/validation do not compile with this patch applied.

On Thu, Jan 15, 2015 at 1:48 PM, Bill Fischofer 
mailto:bill.fischo...@linaro.org>> wrote:
Initial comment:

Patch series applies, however appears incomplete as test/validation/odp_queue.c 
hasn't been updated:

odp_queue.c: In function ‘init_queue_suite’:
odp_queue.c:18:2: error: unknown type name ‘odp_buffer_pool_t’
  odp_buffer_pool_t pool;
  ^
odp_queue.c:19:2: error: unknown type name ‘odp_buffer_pool_param_t’
  odp_buffer_pool_param_t params;
  ^
odp_queue.c:21:8: error: request for member ‘buf_size’ in something not a 
structure or union
  params.buf_size  = 0;
^
odp_queue.c:22:8: error: request for member ‘buf_align’ in something not a 
structure or union
  params.buf_align = ODP_CACHE_LINE_SIZE;
^
odp_queue.c:23:8: error: request for member ‘num_bufs’ in something not a 
structure or union
  params.num_bufs  = 1024 * 10;
^
odp_queue.c:24:8: error: request for member ‘buf_type’ in something not a 
structure or union
  params.buf_type  = ODP_BUFFER_TYPE_RAW;
^
odp_queue.c:24:21: error: ‘ODP_BUFFER_TYPE_RAW’ undeclared (first use in this 
function)
  params.buf_type  = ODP_BUFFER_TYPE_RAW;
 ^
odp_queue.c:24:21: note: each undeclared identifier is reported only once for 
each function it appears in
odp_queue.c:26:2: error: implicit declaration of function 
‘odp_buffer_pool_create’ [-Werror=implicit-function-declaration]
  pool = odp_buffer_pool_create("msg_pool", ODP_SHM_NULL, ¶ms);
  ^
odp_queue.c:26:2: error: nested extern declaration of ‘odp_buffer_pool_create’ 
[-Werror=nested-externs]
odp_queue.c:28:6: error: ‘ODP_BUFFER_POOL_INVALID’ undeclared (first use in 
this function)
  if (ODP_BUFFER_POOL_INVALID == pool) {
  ^
odp_queue.c: In function ‘test_odp_queue_sunnyday’:
odp_queue.c:40:2: error: unknown type name ‘odp_buffer_pool_t’
  odp_buffer_pool_t msg_pool;
  ^
odp_queue.c:68:2: error: implicit declaration of function 
‘odp_buffer_pool_lookup’ [-Werror=implicit-function-declaration]
  msg_pool = odp_buffer_pool_lookup("msg_pool");
  ^
odp_queue.c:68:2: error: nested extern declaration of ‘odp_buffer_pool_lookup’ 
[-Werror=nested-externs]
cc1: all warnings being treated as errors
Makefile:843: recipe for target 'odp_queue.o' failed
make[2]: *** [odp_queue.o] Error 1
make[2]: Leaving directory '/home/bill/linaro/events/test/validation'
Makefile:369: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/bill/linaro/events/test'
Makefile:454: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1
bill@ubuntu:~/linaro/events$


On Thu, Jan 15, 2015 at 9:40 AM, Petri Savolainen 
mailto:petri.savolai...@linaro.org>> wrote:
This patches introduces odp_event_t and replaces with that the usage of
odp_buffer_t as the super class for other "buffer types". What used to be a
buffer type is now an event type.

There are some lines over 80 char, since those are caused by temporary
event <-> buffer, packet -> event -> buffer conversions and should be cleaned up
from the implementation anyway.

Petri Savolainen (15):
  api: event: Add odp_event_t
  api: event: odp_schedule and odp_queue_enq
  api: event: schedule_multi and queue_enq_multi
  api: event: odp_queue_deq
  api: event: odp_queue_deq_multi
  api: buffer: Removed odp_buffer_type
  api: packet: Removed odp_packet_to_buffer
  api: packet: Removed odp_packet_from_buffer
  api: timer: Use odp_event_t instead of odp_buffer_t
  api: crypto: Use odp_event_t instead of odp_buffer_t
  linux-generic: crypto: Use packet alloc for packet
  api: buffer_pool: Rename odp_buffer_pool.h to odp_pool.h
  api: pool: Rename pool params and remove buffer types
  api: pool: Rename odp_buffer_pool_ to odp_pool_
  api: config: Renamed ODP_CONFIG_BUFFER_POOLS

 example/generator/odp_generator.c  |  38 ++---
 example/ipsec/odp_ipsec.c  |  70 
 example/ipsec/odp_ipsec_cache.c|   4 +-
 example/ipsec/odp_ipsec_cache.h|   2 +-
 example/ipsec/odp_ipsec_loop_db.c  |   2 +-
 example/ipsec/odp_ipsec_loop_db.h  |  12 +-
 example/ipsec/odp_ipsec_stream.c   |  20 +--
 example/ipsec/odp_ipsec_stream.h   |   2 +-
 example/l2fwd/odp_l2fwd.c  |  28 +--
 example/packet/odp_pktio.c |  28 +--
 example/timer/odp_timer_test.c |  64 +++
 platform/linux-generic/Makefile.am |   4 +-
 platform/linux-generic/include/api/od

Re: [lng-odp] [PATCH] example: odp_timer_test.c: bug 1068 - odp_timer_test aborts

[Savolainen, Petri (NSN - FI/Espoo)]

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Ola Liljedahl
> Sent: Thursday, January 15, 2015 12:07 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCH] example: odp_timer_test.c: bug 1068 -
> odp_timer_test aborts
> 
> Since the scheduler does not guarantee fairness in scheduling, threads
> must
> time out and check if the example is still running. If this is the case,
> just restart the scheduler loop (not the whole example loop which may have
> other side effects, e.g. resetting timers with some random tick value),
> otherwise break out of the example loop which will terminate the example.
> 
> Signed-off-by: Ola Liljedahl 
> ---
> (This document/code contribution attached is provided under the terms of
> agreement LES-LTM-21309)
> 
>  example/timer/odp_timer_test.c | 21 +++--
>  1 file changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/example/timer/odp_timer_test.c
> b/example/timer/odp_timer_test.c
> index 5de499b..dfd6c70 100644
> --- a/example/timer/odp_timer_test.c
> +++ b/example/timer/odp_timer_test.c
> @@ -126,13 +126,22 @@ static void test_abs_timeouts(int thr, test_args_t
> *args)
>   }
> 
>   /* Get the next expired timeout */
> - /* Use 1.5 second timeout for scheduler */
> - uint64_t sched_tmo = odp_schedule_wait_time(15ULL);
> - buf = odp_schedule(&queue, sched_tmo);
> - /* Check if odp_schedule() timed out, possibly there are no
> -  * remaining timeouts to receive */
> + /* We invoke the scheduler in a loop with a timeout because
> +  * we are not guaranteed to receive any more timeouts. The
> +  * scheduler isn't guaranteeing fairness when scheduling
> +  * buffers to threads */
> + do {
> + /* Use 1.5 second timeout for scheduler */
> + uint64_t sched_tmo =
> + odp_schedule_wait_time(15ULL);

No need to repeat wait time conversion in the loop. It's better to keep it out 
side of the loop since this is an example and should demonstrate the 
correct/elegant way of using the APIs.

-Petri

> + buf = odp_schedule(&queue, sched_tmo);
> + /* Check if odp_schedule() timed out, possibly there
> +  * are no remaining timeouts to receive */
> + } while (buf == ODP_BUFFER_INVALID &&
> +  (int)odp_atomic_load_u32(&remain) > 0);
> +
>   if (buf == ODP_BUFFER_INVALID)
> - continue; /* Re-check the remain counter */
> + break; /* No more timeouts */
>   if (odp_buffer_type(buf) != ODP_BUFFER_TYPE_TIMEOUT) {
>   /* Not a default timeout buffer */
>   EXAMPLE_ABORT("Unexpected buffer type (%u) received\n",
> --
> 1.9.1
> 
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp

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

Re: [lng-odp] [PATCHv3 0/9] implement odp_cpumask to the latest spec

[Savolainen, Petri (NSN - FI/Espoo)]

For the entire patch set:

Reviewed-by: Petri Savolainen 


> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Anders Roxell
> Sent: Thursday, January 15, 2015 12:48 AM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCHv3 0/9] implement odp_cpumask to the latest spec
> 
> Hi,
> 
> Tried to split up Robbies odp_cpumask into "smaller" and more
> easily built chunks.
> 
> Here are the propsed modifcations for ODP 1.0 to coremask
> and the linux helper routines.
> 
> v1 - Updated coremask library to use the CPU_xxx libraries
>  directly, renamed APIs to "cpumask" and updated the linux
>  helper routines to take CPU masks instead of a starting
>  CPU and count. Changed parameter ordering to be consistent
>  with other ODP APIs. Updated the examples/tests to use
>  the modified APIs.
> 
> v2 - Got in too big of a hurry and forgot to rebase
> 
> v3 - Split patches to allow applying patches
>  individually. Swapped arguments to CPU mask to/from
>  string routines (to match ODP API conventions) and added
>  missing const to several API paramters in CPU mask and linux
>  files.
> 
> Robbie King (9):
>   api: cpumask: rename API and use CPU_SET(3) for impl
>   api: cpumask: reorder the input vars to match convention
>   linux-generic: cpumask: remove unneeded define
>   api: cpumask: add odp_cpumask_copy
>   api: cpumask: add odp_cpumask_first
>   api: cpumask: add odp_cpumask_last
>   api: cpumask: add odp_cpumask_next
>   helper: linux: add odph_linux_cpumask_default
>   helper: linux: use cpumask in linux thread/proc
> 
>  example/generator/odp_generator.c |  48 +++---
>  example/ipsec/odp_ipsec.c |  30 ++--
>  example/l2fwd/odp_l2fwd.c |  43 +++--
>  example/packet/odp_pktio.c|  37 ++--
>  example/timer/odp_timer_test.c|  25 ++-
>  helper/include/odph_linux.h   |  28 ++--
>  platform/linux-generic/Makefile.am|   4 +-
>  platform/linux-generic/include/api/odp.h  |   2 +-
>  platform/linux-generic/include/api/odp_coremask.h | 188 -
> 
>  platform/linux-generic/include/api/odp_cpumask.h  | 177
> 
>  platform/linux-generic/include/api/odp_queue.h|   6 +-
>  platform/linux-generic/odp_coremask.c | 109 
>  platform/linux-generic/odp_cpumask.c  | 195
> ++
>  platform/linux-generic/odp_linux.c| 107 +---
>  test/api_test/odp_common.c|  13 +-
>  test/performance/odp_scheduling.c |  30 ++--
>  test/validation/common/odp_cunit_common.c |   5 +-
>  17 files changed, 588 insertions(+), 459 deletions(-)
>  delete mode 100644 platform/linux-generic/include/api/odp_coremask.h
>  create mode 100644 platform/linux-generic/include/api/odp_cpumask.h
>  delete mode 100644 platform/linux-generic/odp_coremask.c
>  create mode 100644 platform/linux-generic/odp_cpumask.c
> 
> --
> 2.1.4
> 
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp

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

Re: [lng-odp] [PATCH v1] api: Move Pktio related APIs to pktio Header file

[Savolainen, Petri (NSN - FI/Espoo)]

Reviewed-by: Petri Savolainen 

A patch set (one type of modification per patch) would have been better 
approach, but I'm OK with this since changes were trivial.


-Petri



> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Balasubramanian Manoharan
> Sent: Wednesday, January 14, 2015 8:05 AM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCH v1] api: Move Pktio related APIs to pktio Header
> file
> 
> The following APIs are setting parameters to pktio handle and are hence
> moved from classification header to pktio header file.
>   odp_pktio_default_cos_set()
>   odp_pktio_error_cos_set()
>   odp_pktio_skip_set()
>   odp_pktio_headroom_set()
> 
> This patch also modifies the error return values in API description
> from -1 to non-zero value
> 
> Signed-off-by: Balasubramanian Manoharan 
> ---
>  .../linux-generic/include/api/odp_classification.h | 92 -
> -
>  platform/linux-generic/include/api/odp_packet_io.h | 55 +
>  .../linux-generic/include/api/odp_platform_types.h |  3 +
>  platform/linux-generic/odp_classification.c| 22 +++---
>  platform/linux-generic/odp_init.c  |  2 +-
>  5 files changed, 86 insertions(+), 88 deletions(-)
> 
> diff --git a/platform/linux-generic/include/api/odp_classification.h
> b/platform/linux-generic/include/api/odp_classification.h
> index 4c9674b..46189bc 100644
> --- a/platform/linux-generic/include/api/odp_classification.h
> +++ b/platform/linux-generic/include/api/odp_classification.h
> @@ -22,7 +22,6 @@ extern "C" {
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
> 
>  /** @defgroup odp_classification ODP CLASSIFICATION
> @@ -30,11 +29,6 @@ extern "C" {
>   *  @{
>   */
> 
> -/**
> - * Class of service instance type
> - */
> -typedef uint32_t odp_cos_t;
> -
> 
>  /**
>   * flow signature type, only used for packet metadata field.
> @@ -95,7 +89,7 @@ odp_cos_t odp_cos_create(const char *name);
>   *
>   * @param[in]cos_id  class-of-service instance.
>   *
> - * @return   0 on success, -1 on error.
> + * @return   0 on success, non-zero on error.
>   */
>  int odp_cos_destroy(odp_cos_t cos_id);
> 
> @@ -108,7 +102,7 @@ int odp_cos_destroy(odp_cos_t cos_id);
>   *   of this specific class of service
>   *   will be enqueued.
>   *
> - * @return   0 on success, -1 on error.
> + * @return   0 on success, non-zero on error.
>   */
>  int odp_cos_set_queue(odp_cos_t cos_id, odp_queue_t queue_id);
> 
> @@ -118,67 +112,13 @@ int odp_cos_set_queue(odp_cos_t cos_id, odp_queue_t
> queue_id);
>   * @param[in]cos_id  class-of-service instance.
>   * @param[in]drop_policy Desired packet drop policy for this 
> class.
>   *
> - * @return   0 on success, -1 on error.
> + * @return   0 on success, non-zero on error.
>   *
>   * @note Optional.
>   */
>  int odp_cos_set_drop(odp_cos_t cos_id, odp_drop_e drop_policy);
> 
>  /**
> - * Setup per-port default class-of-service.
> - *
> - * @param[in]pktio_inIngress port identifier.
> - * @param[in]default_cos Class-of-service set to all packets 
> arriving
> - *   at the pktio_in ingress port,
> - *   unless overridden by subsequent
> - *   header-based filters.
> - *
> - * @return   0 on success, -1 on error.
> - */
> -int odp_pktio_set_default_cos(odp_pktio_t pktio_in, odp_cos_t
> default_cos);
> -
> -/**
> - * Setup per-port error class-of-service
> - *
> - * @param[in]pktio_inIngress port identifier.
> - * @param[in]error_cos   class-of-service set to all packets 
> arriving
> - *   at the pktio_in ingress port
> - *   that contain an error.
> - *
> - * @return   0 on success, -1 on error.
> - *
> - * @note Optional.
> - */
> -int odp_pktio_set_error_cos(odp_pktio_t pktio_in, odp_cos_t error_cos);
> -
> -/**
> - * Setup per-port header offset
> - *
> - * @param[in]pktio_inIngress port identifier.
> - * @param[in]offset  Number of bytes the classifier must
> skip.
> - *
> - * @return   0 on success, -1 on error.
> - * @note  Optional.
> - *
> - */
> -int odp_pktio_set_skip(odp_pktio_t pktio_in, size_t offset);
> -
> -/**
> - * Specify per-port buffer headroom
> - *
> - * @param[in]pktio_inIngress port identifier.
> - * @param[in]headroomNumber of bytes of space preceding
> - *   packet data to reserve for use as headroom.
> - *   Must not exceed the implementation
> - *   defined ODP_PACKET_MAX_HEADROOM.
> - *
> - * @return   0 on su

Re: [lng-odp] [PATCH 1/2] api: remove odp_compiler.h

[Savolainen, Petri (NSN - FI/Espoo)]

Reviewed-by: Petri Savolainen 

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Mike Holmes
> Sent: Wednesday, January 14, 2015 12:06 AM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCH 1/2] api: remove odp_compiler.h
> 
> Compiler information should be predominately platform specific and not
> part of the API.
> The only part of the API needing these definitions is odp_byteorder.h so
> move the definition there and delete odp_compiler.h
> 
> Signed-off-by: Mike Holmes 
> ---
>  platform/linux-generic/Makefile.am |  1 -
>  platform/linux-generic/include/api/odp.h   |  2 -
>  platform/linux-generic/include/api/odp_byteorder.h | 27 +++-
>  platform/linux-generic/include/api/odp_compiler.h  | 51 -
> -
>  4 files changed, 26 insertions(+), 55 deletions(-)
>  delete mode 100644 platform/linux-generic/include/api/odp_compiler.h
> 
> diff --git a/platform/linux-generic/Makefile.am b/platform/linux-
> generic/Makefile.am
> index 4535c57..51cf69c 100644
> --- a/platform/linux-generic/Makefile.am
> +++ b/platform/linux-generic/Makefile.am
> @@ -14,7 +14,6 @@ include_HEADERS = \
> $(top_srcdir)/platform/linux-
> generic/include/api/odp_buffer_pool.h \
> $(top_srcdir)/platform/linux-
> generic/include/api/odp_byteorder.h \
> $(top_srcdir)/platform/linux-
> generic/include/api/odp_classification.h \
> -   $(top_srcdir)/platform/linux-
> generic/include/api/odp_compiler.h \
> $(top_srcdir)/platform/linux-
> generic/include/api/odp_config.h \
> $(top_srcdir)/platform/linux-
> generic/include/api/odp_coremask.h \
> $(top_srcdir)/platform/linux-
> generic/include/api/odp_crypto.h \
> diff --git a/platform/linux-generic/include/api/odp.h b/platform/linux-
> generic/include/api/odp.h
> index b7b1ca9..920fc58 100644
> --- a/platform/linux-generic/include/api/odp.h
> +++ b/platform/linux-generic/include/api/odp.h
> @@ -19,10 +19,8 @@ extern "C" {
>  #endif
> 
>  #include 
> -
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/platform/linux-generic/include/api/odp_byteorder.h
> b/platform/linux-generic/include/api/odp_byteorder.h
> index 5890011..f5514d9 100644
> --- a/platform/linux-generic/include/api/odp_byteorder.h
> +++ b/platform/linux-generic/include/api/odp_byteorder.h
> @@ -21,7 +21,32 @@ extern "C" {
>  #include 
>  #include 
>  #include 
> -#include 
> +
> +/** @addtogroup odp_compiler_optim
> + *  Macro for old compilers
> + *  @{
> + */
> +
> +/** @internal GNU compiler version */
> +#define GCC_VERSION (__GNUC__ * 1 \
> + + __GNUC_MINOR__ * 100 \
> + + __GNUC_PATCHLEVEL__)
> +
> +/**
> + * @internal
> + * Compiler __builtin_bswap16() is not available on all platforms
> + * until GCC 4.8.0 - work around this by offering __odp_builtin_bswap16()
> + * Don't use this function directly, instead see odp_byteorder.h
> + */
> +#if GCC_VERSION < 40800
> +#define __odp_builtin_bswap16(u16) u16)&0x00ff) << 8)|(((u16)&0xff00)
> >> 8))
> +#else
> +#define __odp_builtin_bswap16(u16) __builtin_bswap16(u16)
> +#endif
> +
> +/**
> + * @}
> + */
> 
>  /** @defgroup odp_compiler_optim ODP COMPILER / OPTIMIZATION
>   *  Macros that check byte order and byte converting operations.
> diff --git a/platform/linux-generic/include/api/odp_compiler.h
> b/platform/linux-generic/include/api/odp_compiler.h
> deleted file mode 100644
> index 71a4431..000
> --- a/platform/linux-generic/include/api/odp_compiler.h
> +++ /dev/null
> @@ -1,51 +0,0 @@
> -/* Copyright (c) 2014, Linaro Limited
> - * All rights reserved.
> - *
> - * SPDX-License-Identifier: BSD-3-Clause
> - */
> -
> -
> -/**
> - * @file
> - *
> - * Compiler related
> - */
> -
> -#ifndef ODP_COMPILER_H_
> -#define ODP_COMPILER_H_
> -
> -#ifdef __cplusplus
> -extern "C" {
> -#endif
> -
> -/** @addtogroup odp_compiler_optim
> - *  Macro for old compilers
> - *  @{
> - */
> -
> -/** @internal GNU compiler version */
> -#define GCC_VERSION (__GNUC__ * 1 \
> - + __GNUC_MINOR__ * 100 \
> - + __GNUC_PATCHLEVEL__)
> -
> -/**
> - * @internal
> - * Compiler __builtin_bswap16() is not available on all platforms
> - * until GCC 4.8.0 - work around this by offering __odp_builtin_bswap16()
> - * Don't use this function directly, instead see odp_byteorder.h
> - */
> -#if GCC_VERSION < 40800
> -#define __odp_builtin_bswap16(u16) u16)&0x00ff) << 8)|(((u16)&0xff00)
> >> 8))
> -#else
> -#define __odp_builtin_bswap16(u16) __builtin_bswap16(u16)
> -#endif
> -
> -/**
> - * @}
> - */
> -
> -#ifdef __cplusplus
> -}
> -#endif
> -
> -#endif
> --
> 2.1.0
> 
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp

___

Re: [lng-odp] [PATCH 2/2] linux-generic: packet_socket: remove include of odp.h

[Savolainen, Petri (NSN - FI/Espoo)]

Reviewed-by: Petri Savolainen 

> -Original Message-
> From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-
> boun...@lists.linaro.org] On Behalf Of ext Mike Holmes
> Sent: Wednesday, January 14, 2015 12:06 AM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCH 2/2] linux-generic: packet_socket: remove
> include of odp.h
> 
> Signed-off-by: Mike Holmes 
> 
> Implementations should not include odp.h directly, this is a helper for
> applications only.
> 
> ---
>  platform/linux-generic/odp_packet_socket.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/platform/linux-generic/odp_packet_socket.c b/platform/linux-
> generic/odp_packet_socket.c
> index da7fb2c..5b30c19 100644
> --- a/platform/linux-generic/odp_packet_socket.c
> +++ b/platform/linux-generic/odp_packet_socket.c
> @@ -34,7 +34,6 @@
>  #include 
>  #include 
> 
> -#include 
>  #include 
>  #include 
>  #include 
> --
> 2.1.0
> 
> 
> ___
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp

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

Re: [lng-odp] [PATCHv2 1/2] Convert linux thread/proc helpers to use core mask

[Savolainen, Petri (NSN - FI/Espoo)]

It makes sense. I managed to mix things up. Should we add documentation that 
"cpu" parameter is typically coming from odp_cpumask_first().

-Petri

> -Original Message-
> From: ext Robbie King (robking) [mailto:robk...@cisco.com]
> Sent: Tuesday, January 13, 2015 5:23 PM
> To: Savolainen, Petri (NSN - FI/Espoo); lng-odp@lists.linaro.org
> Subject: RE: [lng-odp] [PATCHv2 1/2] Convert linux thread/proc helpers to
> use core mask
> 
> Hey Petri, I think it needs to be there at least the way I am currently
> using it.  You begin the process by calling "odp_cpumask_first" to get
> your starting CPU, and the "next" function is the continuation.  So
> the CPU number passed into the function is assumed to be the previously
> set CPU, and we are searching for the next one.  So the "+1" is necessary
> to skip over the CPU passed in (else you would just keep finding the
> same CPU).
> 
> If you wanted to only use "odp_cpumask_next", I think it could be
> done with passing in "-1" as the CPU to indicate start versus
> continuation.
> 
> Hope this makes sense.
> 
> > +int odp_cpumask_next(const odp_cpumask_t *mask, int cpu)
> > +{
> > +   for (cpu += 1; cpu < CPU_SETSIZE; cpu++)
> 
> 
> First valid cpu ID is 0. So, "cpu += 1" should not be there, right?
> 
> -Petri
> 
> 
> > +   if (odp_cpumask_isset(mask, cpu))
> > +   return cpu;
> > +   return -1;
> > +}
___
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp