Re: [lng-odp] [API-NEXT PATCH 2/4] linux-gen: socket: handle recv/send calls with large burst size

[Elo, Matias (Nokia - FI/Espoo)]

> On 12 Apr 2017, at 18:03, Bill Fischofer  wrote:
> 
> This patch seems orthogonal to the rest of this series. Shouldn't this
> be a separate patch?
> 

The pktio validation test fails without this fix.

The following packet pool patch in the series fixes an issue where the pool to 
didn't allocate enough packets if the requested length (params->pkt.len) 
packets were segmented. As a result of this fix it is now possible to allocate 
more than params->pkt.num packets from the pool, if the requested packet length 
fits into a single segment (or less segments than the original params->pkt.len).

Now, the pktio validation test pktio_test_start_stop() tries to create up to 
1000 packets and then send as many it managed to allocate. After the 
aforementioned change the test manages to allocate 64 packets from the pool 
instead of the previous 32. The socket pktio max tx burst is set to 32, so the 
test will fail.


-Matias

Re: [lng-odp] [PATCH v3 1/2] api: queue: added queue size param

[Bala Manoharan]

Regards,
Bala


On 3 April 2017 at 15:41, Petri Savolainen  wrote:
> Added capability information about maximum number of queues
> and queue sizes. Both are defined per queue type, since
> plain and scheduled queues may have different implementations
> (e.g. one uses HW while the other is SW).
>
> Added queue size parameter, which specifies how large
> storage size application requires in minimum.
>
> Signed-off-by: Petri Savolainen 
> ---
>  include/odp/api/spec/queue.h | 35 ++-
>  1 file changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/include/odp/api/spec/queue.h b/include/odp/api/spec/queue.h
> index 7972fea..9c83322 100644
> --- a/include/odp/api/spec/queue.h
> +++ b/include/odp/api/spec/queue.h
> @@ -100,7 +100,9 @@ typedef enum odp_queue_op_mode_t {
>   * Queue capabilities
>   */
>  typedef struct odp_queue_capability_t {
> -   /** Maximum number of event queues */
> +   /** Maximum number of event queues of any type. Use this in addition 
> to
> + * queue type specific 'max_num', if both queue types are used
> + * simultaneously. */
> uint32_t max_queues;
>
> /** Maximum number of ordered locks per queue */
> @@ -112,6 +114,28 @@ typedef struct odp_queue_capability_t {
> /** Number of scheduling priorities */
> unsigned sched_prios;
>
> +   /** Plain queue capabilities */
> +   struct {
> +   /** Maximum number of a plain queues. */
> +   uint32_t max_num;
> +
> +   /** Maximum number of events a plain queue can store
> + * simultaneously. The value of zero means unlimited. */

As discussed in the ARCH call, I believe the above wordings needs to
be updated to indicate the physical limitation
in the system.

> +   uint32_t max_size;
> +
> +   } plain;
> +
> +   /** Scheduled queue capabilities */
> +   struct {
> +   /** Maximum number of a scheduled queues. */
> +   uint32_t max_num;
> +
> +   /** Maximum number of events a scheduled queue can store
> + * simultaneously. The value of zero means unlimited. */
> +   uint32_t max_size;
> +
> +   } sched;
> +
>  } odp_queue_capability_t;
>
>  /**
> @@ -165,6 +189,15 @@ typedef struct odp_queue_param_t {
>   * The implementation may use this value as a hint for the number of
>   * context data bytes to prefetch. Default value is zero (no hint). 
> */
> uint32_t context_len;
> +
> +   /** Queue size
> + *
> + * The queue must be able to store at minimum this many events
> + * simultaneously. The value must not exceed 'max_size' queue
> + * capability. The value of zero means implementation specific
> + * default size. */
> +   uint32_t size;
> +
>  } odp_queue_param_t;
>
>  /**
> --
> 2.8.1
>

Re: [lng-odp] [PATCH v3 1/2] api: queue: added queue size param

[Honnappa Nagarahalli]

Small change as noted below.


On 12 April 2017 at 10:19, Bill Fischofer  wrote:
> Based on today's ARCH call, this seems to be a good approach, with
> some slight wording clarification (noted below)
>
> On Mon, Apr 3, 2017 at 5:11 AM, Petri Savolainen
>  wrote:
>> Added capability information about maximum number of queues
>> and queue sizes. Both are defined per queue type, since
>> plain and scheduled queues may have different implementations
>> (e.g. one uses HW while the other is SW).
>>
>> Added queue size parameter, which specifies how large
>> storage size application requires in minimum.
>>
>> Signed-off-by: Petri Savolainen 
>> ---
>>  include/odp/api/spec/queue.h | 35 ++-
>>  1 file changed, 34 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/odp/api/spec/queue.h b/include/odp/api/spec/queue.h
>> index 7972fea..9c83322 100644
>> --- a/include/odp/api/spec/queue.h
>> +++ b/include/odp/api/spec/queue.h
>> @@ -100,7 +100,9 @@ typedef enum odp_queue_op_mode_t {
>>   * Queue capabilities
>>   */
>>  typedef struct odp_queue_capability_t {
>> -   /** Maximum number of event queues */
>> +   /** Maximum number of event queues of any type. Use this in addition 
>> to
>> + * queue type specific 'max_num', if both queue types are used
>> + * simultaneously. */
>> uint32_t max_queues;
>
> These fields tell the application how many queues it is guaranteed to
> be able to create, hence this is really a minimum number, not a
> maximum number. An application may in fact be able to create more, but
> it's guaranteed to be able to create at least this number. So I
> suggest the following rename/rewording to clarify this point.
>
>  /** Minimum guaranteed number of event queues of any
> type. Use this in addition to
>   * queue type specific 'min_num', if both queue types are
> used simultaneously */
> uint32_t min_queues;
>
>>
>> /** Maximum number of ordered locks per queue */
>> @@ -112,6 +114,28 @@ typedef struct odp_queue_capability_t {
>> /** Number of scheduling priorities */
>> unsigned sched_prios;
>>
>> +   /** Plain queue capabilities */
>> +   struct {
>> +   /** Maximum number of a plain queues. */
>> +   uint32_t max_num;
>
> /** Minimum guaranteed number of plain queues that
> may be created in this ODP instance */
> uint32_t min_num;
>
>> +
>> +   /** Maximum number of events a plain queue can store
>> + * simultaneously. The value of zero means unlimited. */
>> +   uint32_t max_size;

Can we change the wording to say "The value of zero means limited only
by available resources" or "The value of zero means limited only by
available memory"

This will make it consistent/similar with wordings in other files (for
ex: pool capabilities)

>> +
>> +   } plain;
>> +
>> +   /** Scheduled queue capabilities */
>> +   struct {
>> +   /** Maximum number of a scheduled queues. */
>> +   uint32_t max_num;
>
> /** Minimum guaranteed number of scheduled queues
> that may be created in this ODP instance */
> uint32_t min_num;
>
>> +
>> +   /** Maximum number of events a scheduled queue can store
>> + * simultaneously. The value of zero means unlimited. */
>> +   uint32_t max_size;
>> +
>> +   } sched;
>> +
>>  } odp_queue_capability_t;
>>
>>  /**
>> @@ -165,6 +189,15 @@ typedef struct odp_queue_param_t {
>>   * The implementation may use this value as a hint for the number of
>>   * context data bytes to prefetch. Default value is zero (no hint). 
>> */
>> uint32_t context_len;
>> +
>> +   /** Queue size
>> + *
>> + * The queue must be able to store at minimum this many events
>> + * simultaneously. The value must not exceed 'max_size' queue
>> + * capability. The value of zero means implementation specific
>> + * default size. */
>> +   uint32_t size;
>> +
>>  } odp_queue_param_t;
>>
>>  /**
>> --
>> 2.8.1
>>

Re: [lng-odp] [PATCH v2] build: fix native Clang build on ARMv8

[Dmitry Eremin-Solenikov]

On 12.04.2017 21:30, Brian Brooks wrote:
> The build is broken when using clang on ARM. -mcx16 is being passed to
> clang when building natively on ARM. This combined with -Werror causes
> the breakage. Fix it by skipping anything related to -mcx16 when not
> building for x86-based architectures. See [1] for details.
> 
> [1] https://lists.linaro.org/pipermail/lng-odp/2017-April/029684.html
> 
> v2
>  - Add more description to commit message (Dmitry)
> 
> Signed-off-by: Brian Brooks 
> ---
>  configure.ac | 30 --
>  1 file changed, 16 insertions(+), 14 deletions(-)

Reviewed-by: Dmitry Eremin-Solenikov 

> 
> diff --git a/configure.ac b/configure.ac
> index 9320f360..d364b8dd 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -303,20 +303,22 @@ ODP_CFLAGS="$ODP_CFLAGS -std=c99"
>  # Extra flags for example to suppress certain warning types
>  ODP_CFLAGS="$ODP_CFLAGS $ODP_CFLAGS_EXTRA"
>  
> -#
> -# Check if compiler supports cmpxchng16
> -##
> -if test "${CC}" != "gcc" -o ${CC_VERSION_MAJOR} -ge 5; then
> -   my_save_cflags="$CFLAGS"
> -
> -   CFLAGS=-mcx16
> -   AC_MSG_CHECKING([whether CC supports -mcx16])
> -   AC_COMPILE_IFELSE([AC_LANG_PROGRAM([])],
> - [AC_MSG_RESULT([yes])]
> - [ODP_CFLAGS="$ODP_CFLAGS $CFLAGS"],
> - [AC_MSG_RESULT([no])]
> - )
> -   CFLAGS="$my_save_cflags"
> +##
> +# Check if compiler supports cmpxchng16 on x86-based architectures
> +##
> +if "${host}" == i?86* -o "${host}" == x86*; then
> +  if test "${CC}" != "gcc" -o ${CC_VERSION_MAJOR} -ge 5; then
> + my_save_cflags="$CFLAGS"
> +
> + CFLAGS=-mcx16
> + AC_MSG_CHECKING([whether CC supports -mcx16])
> + AC_COMPILE_IFELSE([AC_LANG_PROGRAM([])],
> + [AC_MSG_RESULT([yes])]
> + [ODP_CFLAGS="$ODP_CFLAGS $CFLAGS"],
> + [AC_MSG_RESULT([no])]
> + )
> + CFLAGS="$my_save_cflags"
> +  fi
>  fi
>  
>  ##
> 


-- 
With best wishes
Dmitry

[lng-odp] [Bug 2940] odp_packet_seg_t fails ABI compatibility between odp-linux and odp-dpdk

[bugzilla-daemon]

https://bugs.linaro.org/show_bug.cgi?id=2940

Bill Fischofer  changed:

   What|Removed |Added

 Status|UNCONFIRMED |IN_PROGRESS
 CC||balakrishna.garapati@linaro
   ||.org
 Ever confirmed|0   |1

--- Comment #1 from Bill Fischofer  ---
Patch http://patches.opendataplane.org/patch/8526/ posted to address this
issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[lng-odp] [Bug 2779] CID 173342: Error handling issues (CHECKED_RETURN)

[bugzilla-daemon]

https://bugs.linaro.org/show_bug.cgi?id=2779

--- Comment #5 from Bill Fischofer  ---
Patch v2 posted at http://patches.opendataplane.org/patch/8525/ to address
additional comments from Maxim.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[lng-odp] [PATCH] abi: packet: restore abi compatibility for odp_packet_seg_t type

[Bill Fischofer]

When running in --enable-abi-compat=yes mode, all ODP types need to be
of pointer width in the default ABI definition. The optimization of the
odp_packet_seg_t type to uint8_t can only be supported when running in
--enable-abi-compate=no mode. Change the ODP packet routines to use
type converter routines that have varying definitions based on whether
we're running in ABI compatibility mode and provide these variant
definitions to enable proper ABI compatibility while still supporting an
optimized typedef for non-ABI mode.

This resolves Bug https://bugs.linaro.org/show_bug.cgi?id=2940

Signed-off-by: Bill Fischofer 
---
 include/odp/arch/default/api/abi/packet.h   |  7 +--
 .../include/odp/api/plat/packet_inlines.h   | 21 ++---
 .../include/odp/api/plat/packet_types.h | 10 ++
 platform/linux-generic/odp_packet.c | 12 +++-
 4 files changed, 40 insertions(+), 10 deletions(-)

diff --git a/include/odp/arch/default/api/abi/packet.h 
b/include/odp/arch/default/api/abi/packet.h
index 60a41b8..4aac75b 100644
--- a/include/odp/arch/default/api/abi/packet.h
+++ b/include/odp/arch/default/api/abi/packet.h
@@ -16,15 +16,18 @@ extern "C" {
 /** @internal Dummy type for strong typing */
 typedef struct { char dummy; /**< @internal Dummy */ } _odp_abi_packet_t;
 
+/** @internal Dummy  type for strong typing */
+typedef struct { char dummy; /**< *internal Dummy */ } _odp_abi_packet_seg_t;
+
 /** @ingroup odp_packet
  *  @{
  */
 
 typedef _odp_abi_packet_t *odp_packet_t;
-typedef uint8_todp_packet_seg_t;
+typedef _odp_abi_packet_seg_t *odp_packet_seg_t;
 
 #define ODP_PACKET_INVALID((odp_packet_t)0x)
-#define ODP_PACKET_SEG_INVALID((odp_packet_seg_t)-1)
+#define ODP_PACKET_SEG_INVALID((odp_packet_seg_t)0x)
 #define ODP_PACKET_OFFSET_INVALID (0x0fff)
 
 typedef enum {
diff --git a/platform/linux-generic/include/odp/api/plat/packet_inlines.h 
b/platform/linux-generic/include/odp/api/plat/packet_inlines.h
index eb36aa9..bd735c1 100644
--- a/platform/linux-generic/include/odp/api/plat/packet_inlines.h
+++ b/platform/linux-generic/include/odp/api/plat/packet_inlines.h
@@ -21,6 +21,20 @@
 /** @internal Inline function offsets */
 extern const _odp_packet_inline_offset_t _odp_packet_inline;
 
+#if ODP_ABI_COMPAT
+/** @internal Inline function @param seg @return */
+static inline int _odp_packet_seg_to_ndx(odp_packet_seg_t seg)
+{
+   return _odp_typeval(seg);
+}
+
+/** @internal Inline function @param ndx @return */
+static inline odp_packet_seg_t _odp_packet_seg_from_ndx(int ndx)
+{
+   return _odp_cast_scalar(odp_packet_seg_t, ndx);
+}
+#endif
+
 /** @internal Inline function @param pkt @return */
 static inline void *_odp_packet_data(odp_packet_t pkt)
 {
@@ -128,20 +142,21 @@ static inline odp_packet_seg_t 
_odp_packet_first_seg(odp_packet_t pkt)
 {
(void)pkt;
 
-   return 0;
+   return _odp_packet_seg_from_ndx(0);
 }
 
 /** @internal Inline function @param pkt @return */
 static inline odp_packet_seg_t _odp_packet_last_seg(odp_packet_t pkt)
 {
-   return _odp_packet_num_segs(pkt) - 1;
+   return _odp_packet_seg_from_ndx(_odp_packet_num_segs(pkt) - 1);
 }
 
 /** @internal Inline function @param pkt @param seg @return */
 static inline odp_packet_seg_t _odp_packet_next_seg(odp_packet_t pkt,
odp_packet_seg_t seg)
 {
-   if (odp_unlikely(seg >= _odp_packet_last_seg(pkt)))
+   if (odp_unlikely(_odp_packet_seg_to_ndx(seg) >=
+_odp_packet_seg_to_ndx(_odp_packet_last_seg(pkt
return ODP_PACKET_SEG_INVALID;
 
return seg + 1;
diff --git a/platform/linux-generic/include/odp/api/plat/packet_types.h 
b/platform/linux-generic/include/odp/api/plat/packet_types.h
index b8f665d..59e8b2f 100644
--- a/platform/linux-generic/include/odp/api/plat/packet_types.h
+++ b/platform/linux-generic/include/odp/api/plat/packet_types.h
@@ -40,6 +40,16 @@ typedef ODP_HANDLE_T(odp_packet_t);
 
 typedef uint8_t odp_packet_seg_t;
 
+static inline int _odp_packet_seg_to_ndx(odp_packet_seg_t seg)
+{
+   return (int)seg;
+}
+
+static inline odp_packet_seg_t _odp_packet_seg_from_ndx(int ndx)
+{
+   return (odp_packet_seg_t)ndx;
+}
+
 #define ODP_PACKET_SEG_INVALID ((odp_packet_seg_t)-1)
 
 typedef enum {
diff --git a/platform/linux-generic/odp_packet.c 
b/platform/linux-generic/odp_packet.c
index b8aac6b..e99e8b8 100644
--- a/platform/linux-generic/odp_packet.c
+++ b/platform/linux-generic/odp_packet.c
@@ -1185,7 +1185,7 @@ void *odp_packet_offset(odp_packet_t pkt, uint32_t 
offset, uint32_t *len,
void *addr = packet_map(pkt_hdr, offset, len, _idx);
 
if (addr != NULL && seg != NULL)
-   *seg = seg_idx;
+   *seg = _odp_packet_seg_from_ndx(seg_idx);
 
return addr;
 }
@@ -1326,20 +1326,22 @@ void 

[lng-odp] [Bug 2940] New: odp_packet_seg_t fails ABI compatibility between odp-linux and odp-dpdk

[bugzilla-daemon]

https://bugs.linaro.org/show_bug.cgi?id=2940

Bug ID: 2940
   Summary: odp_packet_seg_t fails ABI compatibility between
odp-linux and odp-dpdk
   Product: OpenDataPlane - linux- generic reference
   Version: v1.14.0.0
  Hardware: Other
OS: Linux
Status: UNCONFIRMED
  Severity: enhancement
  Priority: ---
 Component: Buffers & Packets
  Assignee: bill.fischo...@linaro.org
  Reporter: bill.fischo...@linaro.org
CC: lng-odp@lists.linaro.org
  Target Milestone: ---

When running in --enable-abi-compat=yes mode the type definition of
odp_packet_seg_t needs to be compatible with other ABI compatible typedefs.
This means it must be of pointer-width. The uint8_t optimization can only be
used when running with --enable-abi-compat=no.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: [lng-odp] [API-NEXT PATCH 0/4] add maximum packet counts to pool info

[Bill Fischofer]

On Wed, Apr 12, 2017 at 7:58 AM, Matias Elo  wrote:
> On some packet pool implementations the number of available packets may vary
> depending on the packet length (examples below). E.g. a packet pool may 
> include
> smaller sub-pools for different packet length ranges.

I'm not sure what the motivation is for this proposed change, but the
pkt.num specified on odp_pool_create() sets the maximum number of
packets that can be allocated from the pool, not the minimum. This is
combined with the pkt.len field to say that pkt.num packets of len
pkt.len can be allocated. If the application allocated packets larger
than this size (up to pkt.max_len) then the actual number of packets
that can be successfully allocated from the pool may be lower than
pkt.num, but it will never be greater.

The reason for wanting the maximum number is to bound the number of
"in flight" packets for QoS purposes. As a pool reaches this limit,
RED and similar algorithms kick in to start dropping packets at RX. If
there is no fixed maximum number of packets that makes QoS processing
erratic.

We had previously floated the idea of allowing pool groups to be
defined which would accommodate the practice where packets get
assigned to different sub-pools based on their size, however this was
seen to be overly complicated, especially on platforms that have
hardware buffer managers. Since PMRs can be used to sort packets into
different CoSes based on len and each of these can have their own pool
associated with them, this was also seen as unnecessary.

Do you have a specific use case that can't be handled by the current structures?

>
> Num. pkts
> A
> |___
> |   |
> |   |___
> |   |
> |Pool 1 |___
> |   |
> |___|__>
> 0  51210242048
> Pkt length (B)
>
> Num. pkts
> A
> |___
> |   |   |
> |   |   |
> |___|Pool 2 |___
> |   |
> |___|__>
> 0  51210242048
> Pkt length (B)
>
> To better describe this kind of pools, add fields to odp_pool_info_t for 
> maximum
> number of packets of any length, maximum number of minimum length packets, and
> maximum number of maximum length packets.
>
> odp_pool_param_t documentation is updated to reflect these new fields.
>
> Small fix is required to the socket pktio to make the validation suite pass.
>
> Matias Elo (4):
>   api: pool: add maximum packet counts to pool info
>   linux-gen: socket: handle recv/send calls with large burst size
>   linux-gen: pool: add new maximum packet count fields to pool info
>   validation: pool: add tests for new odp_pool_info_t fields
>
>  include/odp/api/spec/pool.h| 43 
> +++---
>  .../linux-generic/include/odp_packet_internal.h| 22 +++
>  platform/linux-generic/include/odp_pool_internal.h |  1 +
>  platform/linux-generic/odp_packet.c| 22 ---
>  platform/linux-generic/odp_pool.c  | 21 +--
>  platform/linux-generic/pktio/socket.c  |  4 +-
>  test/common_plat/validation/api/pool/pool.c| 20 ++
>  7 files changed, 93 insertions(+), 40 deletions(-)
>
> --
> 2.7.4
>

Re: [lng-odp] [PATCH] example: l3fwd: check rc from odph_eth_addr_parse()

[Bill Fischofer]

On Wed, Apr 12, 2017 at 2:10 PM, Maxim Uvarov  wrote:
> On 04/06/17 00:16, Bill Fischofer wrote:
>> Resolve Bug https://bugs.linaro.org/show_bug.cgi?id=2779 by checking
>> the return code from odph_eth_addr_parse() and failing the call if
>> dst_mac is unparseable.
>>
>> Signed-off-by: Bill Fischofer 
>> ---
>>  example/l3fwd/odp_l3fwd_db.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/example/l3fwd/odp_l3fwd_db.c b/example/l3fwd/odp_l3fwd_db.c
>> index 082b2c2..7d1efd5 100644
>> --- a/example/l3fwd/odp_l3fwd_db.c
>> +++ b/example/l3fwd/odp_l3fwd_db.c
>> @@ -394,7 +394,8 @@ int create_fwd_db_entry(char *input, char **oif, uint8_t 
>> **dst_mac)
>>   *oif = entry->oif;
>>   break;
>>   case 2:
>> - odph_eth_addr_parse(>dst_mac, token);
>> + if (odph_eth_addr_parse(>dst_mac, token) < 0)
>> + return -1;
>
> free(local) is missing

Thanks! v2 sent.

>
> Maxim.
>
>>   *dst_mac = entry->dst_mac.addr;
>>   break;
>>
>>
>

[lng-odp] [PATCHv2] example: l3fwd: check rc from odph_eth_addr_parse()

[Bill Fischofer]

Resolve Bug https://bugs.linaro.org/show_bug.cgi?id=2779 by checking
the return code from odph_eth_addr_parse() and failing the call if
dst_mac is unparseable.

Signed-off-by: Bill Fischofer 
---
Changes in v2:
- Don't forget to free(local) (Maxim comment)

 example/l3fwd/odp_l3fwd_db.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/example/l3fwd/odp_l3fwd_db.c b/example/l3fwd/odp_l3fwd_db.c
index 082b2c2..0670aa4 100644
--- a/example/l3fwd/odp_l3fwd_db.c
+++ b/example/l3fwd/odp_l3fwd_db.c
@@ -394,7 +394,10 @@ int create_fwd_db_entry(char *input, char **oif, uint8_t 
**dst_mac)
*oif = entry->oif;
break;
case 2:
-   odph_eth_addr_parse(>dst_mac, token);
+   if (odph_eth_addr_parse(>dst_mac, token) < 0) {
+   free(local);
+   return -1;
+   }
*dst_mac = entry->dst_mac.addr;
break;
 
-- 
2.9.3

Re: [lng-odp] [PATCH] example: l3fwd: check rc from odph_eth_addr_parse()

[Maxim Uvarov]

On 04/06/17 00:16, Bill Fischofer wrote:
> Resolve Bug https://bugs.linaro.org/show_bug.cgi?id=2779 by checking
> the return code from odph_eth_addr_parse() and failing the call if
> dst_mac is unparseable.
> 
> Signed-off-by: Bill Fischofer 
> ---
>  example/l3fwd/odp_l3fwd_db.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/example/l3fwd/odp_l3fwd_db.c b/example/l3fwd/odp_l3fwd_db.c
> index 082b2c2..7d1efd5 100644
> --- a/example/l3fwd/odp_l3fwd_db.c
> +++ b/example/l3fwd/odp_l3fwd_db.c
> @@ -394,7 +394,8 @@ int create_fwd_db_entry(char *input, char **oif, uint8_t 
> **dst_mac)
>   *oif = entry->oif;
>   break;
>   case 2:
> - odph_eth_addr_parse(>dst_mac, token);
> + if (odph_eth_addr_parse(>dst_mac, token) < 0)
> + return -1;

free(local) is missing

Maxim.

>   *dst_mac = entry->dst_mac.addr;
>   break;
>  
> 

Re: [lng-odp] [PATCHv4] linux-generic: debug: enable helper use from c++ programs

[Bill Fischofer]

So what's changed between now and when Travis reported this passing
for me? See https://travis-ci.org/Linaro/odp/builds/217908015

On Wed, Apr 12, 2017 at 1:58 PM, Brian Brooks  wrote:
> On Fri, Mar 31, 2017 at 10:02 AM, Maxim Uvarov  
> wrote:
>> rechecked this patch and it fails:
>> https://travis-ci.org/muvarov/odp/jobs/217195437
>>
>> Maxim.
>>
>> On 02/08/17 04:04, Bill Fischofer wrote:
>>> I've done a fair amount of experimentation with using variants of
>>> Brian's suggested macros. This works for C but for C++ it results in
>>> an error message saying that it can't do relocation and to please
>>> compile with -fPIC, which we've already determined is an unacceptable
>>> requirement for ODP programs. These sort of issues are why
>>> _Static_assert() and static_assert() were introduced to the languages
>>> in the first place.
>>>
>>> Can we require -std=c++11 when using ODP?
>
> Would it be possible to move this macro to internal-only where C is
> used? The problem goes away if we are allowed to lower it. I don't
> know why such a macro exists at the top-level API to begin with.
>
>>> On Tue, Feb 7, 2017 at 8:42 AM, Bill Fischofer
>>>  wrote:
 Given these issues with obsolete compiler levels, it may be simpler to
 go with Brian's suggestion and just use some simple macros. I'll post
 a v4 along those lines.

 On Tue, Feb 7, 2017 at 7:51 AM, Maxim Uvarov  
 wrote:
> On 02/07/17 16:39, Bill Fischofer wrote:
>> The errors being reported here are on unchanged code paths with an
>> older clang version (3.4.0 vs.4.2.1). Not sure why you'd see that here
>> and not in the unchanged code.
>>
>> Also, this run is reporting doxygen issues with the traffic manager
>> that I don't see running locally:
>>
>> $ make doxygen-doc
>>   DXGEN  doc/application-api-guide/Doxyfile
>> warning: ignoring unsupported tag `HTML_EXTRA_STYLESHEET =' at line
>> 26, file ./doc/Doxyfile_common
>> error: Unexpected start tag `services' found in 
>> scope='class/memberdecl/'!
>> error: Unexpected start tag `interfaces' found in 
>> scope='class/memberdecl/'!
>> error: Unexpected start tag `services' found in scope='class/memberdef/'!
>> error: Unexpected start tag `interfaces' found in 
>> scope='class/memberdef/'!
>> error: Unexpected start tag `constantgroups' found in
>> scope='namespace/memberdecl/'!
>> error: Unexpected start tag `constantgroups' found in 
>> scope='file/memberdecl/'!
>> /home/travis/build/muvarov/odp/doc/application-api-guide/api_guide_lines.dox:10:
>> warning: Found unknown command `\tableofcontents'
>> /home/travis/build/muvarov/odp/doc/application-api-guide/release.dox:8:
>> warning: Found unknown command `\tableofcontents'
>> /home/travis/build/muvarov/odp/include/odp/api/spec/traffic_mngr.h:1717:
>> warning: expected whitespace after param command
>> /home/travis/build/muvarov/odp/include/odp/api/spec/traffic_mngr.h:1691:
>> warning: argument 'inout' of command @param is not found in the
>> argument list of odp_tm_node_fanin_info(odp_tm_node_t tm_node,
>> odp_tm_node_fanin_info_t *info)
>> /home/travis/build/muvarov/odp/include/odp/api/spec/traffic_mngr.h:1691:
>> warning: The following parameters of
>> odp_tm_node_fanin_info(odp_tm_node_t tm_node, odp_tm_node_fanin_info_t
>> *info) are not documented:
>>   parameter 'info'
>>   DXGEN  doc/helper-guide/Doxyfile
>> warning: ignoring unsupported tag `HTML_EXTRA_STYLESHEET =' at line
>> 31, file ./doc/helper-guide/Doxyfile
>> error: Unexpected start tag `services' found in 
>> scope='class/memberdecl/'!
>> error: Unexpected start tag `interfaces' found in 
>> scope='class/memberdecl/'!
>> error: Unexpected start tag `services' found in scope='class/memberdef/'!
>> error: Unexpected start tag `interfaces' found in 
>> scope='class/memberdef/'!
>> error: Unexpected start tag `constantgroups' found in
>> scope='namespace/memberdecl/'!
>> error: Unexpected start tag `constantgroups' found in 
>> scope='file/memberdecl/'!
>>
>> So do we also have a doxygen version issue on these systems?
>>
>
>
> looks like yes. I also do not see comment locally.
>
> we also need some way to return non 0 if doxygen reported an error.
>
> The command "make doxygen-doc" exited with 0.
>
>
>
>> On Tue, Feb 7, 2017 at 7:30 AM, Maxim Uvarov  
>> wrote:
>>> I pushed it to github and test failed:
>>>
>>> https://api.travis-ci.org/jobs/199201799/log.txt?deansi=true
>>>
>>> Maxim.
>>>
>>>
>>> On 02/07/17 05:51, Brian Brooks wrote:
 On 02/06 13:14:17, Bill Fischofer wrote:
> Ping. Brian can you please verify that this now works on 

Re: [lng-odp] [PATCHv4] linux-generic: debug: enable helper use from c++ programs

[Brian Brooks]

On Fri, Mar 31, 2017 at 10:02 AM, Maxim Uvarov  wrote:
> rechecked this patch and it fails:
> https://travis-ci.org/muvarov/odp/jobs/217195437
>
> Maxim.
>
> On 02/08/17 04:04, Bill Fischofer wrote:
>> I've done a fair amount of experimentation with using variants of
>> Brian's suggested macros. This works for C but for C++ it results in
>> an error message saying that it can't do relocation and to please
>> compile with -fPIC, which we've already determined is an unacceptable
>> requirement for ODP programs. These sort of issues are why
>> _Static_assert() and static_assert() were introduced to the languages
>> in the first place.
>>
>> Can we require -std=c++11 when using ODP?

Would it be possible to move this macro to internal-only where C is
used? The problem goes away if we are allowed to lower it. I don't
know why such a macro exists at the top-level API to begin with.

>> On Tue, Feb 7, 2017 at 8:42 AM, Bill Fischofer
>>  wrote:
>>> Given these issues with obsolete compiler levels, it may be simpler to
>>> go with Brian's suggestion and just use some simple macros. I'll post
>>> a v4 along those lines.
>>>
>>> On Tue, Feb 7, 2017 at 7:51 AM, Maxim Uvarov  
>>> wrote:
 On 02/07/17 16:39, Bill Fischofer wrote:
> The errors being reported here are on unchanged code paths with an
> older clang version (3.4.0 vs.4.2.1). Not sure why you'd see that here
> and not in the unchanged code.
>
> Also, this run is reporting doxygen issues with the traffic manager
> that I don't see running locally:
>
> $ make doxygen-doc
>   DXGEN  doc/application-api-guide/Doxyfile
> warning: ignoring unsupported tag `HTML_EXTRA_STYLESHEET =' at line
> 26, file ./doc/Doxyfile_common
> error: Unexpected start tag `services' found in scope='class/memberdecl/'!
> error: Unexpected start tag `interfaces' found in 
> scope='class/memberdecl/'!
> error: Unexpected start tag `services' found in scope='class/memberdef/'!
> error: Unexpected start tag `interfaces' found in 
> scope='class/memberdef/'!
> error: Unexpected start tag `constantgroups' found in
> scope='namespace/memberdecl/'!
> error: Unexpected start tag `constantgroups' found in 
> scope='file/memberdecl/'!
> /home/travis/build/muvarov/odp/doc/application-api-guide/api_guide_lines.dox:10:
> warning: Found unknown command `\tableofcontents'
> /home/travis/build/muvarov/odp/doc/application-api-guide/release.dox:8:
> warning: Found unknown command `\tableofcontents'
> /home/travis/build/muvarov/odp/include/odp/api/spec/traffic_mngr.h:1717:
> warning: expected whitespace after param command
> /home/travis/build/muvarov/odp/include/odp/api/spec/traffic_mngr.h:1691:
> warning: argument 'inout' of command @param is not found in the
> argument list of odp_tm_node_fanin_info(odp_tm_node_t tm_node,
> odp_tm_node_fanin_info_t *info)
> /home/travis/build/muvarov/odp/include/odp/api/spec/traffic_mngr.h:1691:
> warning: The following parameters of
> odp_tm_node_fanin_info(odp_tm_node_t tm_node, odp_tm_node_fanin_info_t
> *info) are not documented:
>   parameter 'info'
>   DXGEN  doc/helper-guide/Doxyfile
> warning: ignoring unsupported tag `HTML_EXTRA_STYLESHEET =' at line
> 31, file ./doc/helper-guide/Doxyfile
> error: Unexpected start tag `services' found in scope='class/memberdecl/'!
> error: Unexpected start tag `interfaces' found in 
> scope='class/memberdecl/'!
> error: Unexpected start tag `services' found in scope='class/memberdef/'!
> error: Unexpected start tag `interfaces' found in 
> scope='class/memberdef/'!
> error: Unexpected start tag `constantgroups' found in
> scope='namespace/memberdecl/'!
> error: Unexpected start tag `constantgroups' found in 
> scope='file/memberdecl/'!
>
> So do we also have a doxygen version issue on these systems?
>


 looks like yes. I also do not see comment locally.

 we also need some way to return non 0 if doxygen reported an error.

 The command "make doxygen-doc" exited with 0.



> On Tue, Feb 7, 2017 at 7:30 AM, Maxim Uvarov  
> wrote:
>> I pushed it to github and test failed:
>>
>> https://api.travis-ci.org/jobs/199201799/log.txt?deansi=true
>>
>> Maxim.
>>
>>
>> On 02/07/17 05:51, Brian Brooks wrote:
>>> On 02/06 13:14:17, Bill Fischofer wrote:
 Ping. Brian can you please verify that this now works on your system.
 It works on my Ubuntu 16.04 system.
>>>
>>> Just built on:
>>>
>>> Ubuntu 16.10 - x86_64
>>> Ubuntu 16.04 - aarch64
>>> Arch - aarch64 & x86_64
>>>
>>> so the previous build error I reported seems to have been resolved.
>>>
 A review would also be nice. :)
>>>

[lng-odp] [Bug 2921] odp_init_global() and odp_pool_create() set errno = 12

[bugzilla-daemon]

https://bugs.linaro.org/show_bug.cgi?id=2921

--- Comment #6 from Maxim Uvarov  ---
yes, please provide patch. I think it might be applicable for current master.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[lng-odp] [PATCH v2] build: fix native Clang build on ARMv8

[Brian Brooks]

The build is broken when using clang on ARM. -mcx16 is being passed to
clang when building natively on ARM. This combined with -Werror causes
the breakage. Fix it by skipping anything related to -mcx16 when not
building for x86-based architectures. See [1] for details.

[1] https://lists.linaro.org/pipermail/lng-odp/2017-April/029684.html

v2
 - Add more description to commit message (Dmitry)

Signed-off-by: Brian Brooks 
---
 configure.ac | 30 --
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/configure.ac b/configure.ac
index 9320f360..d364b8dd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -303,20 +303,22 @@ ODP_CFLAGS="$ODP_CFLAGS -std=c99"
 # Extra flags for example to suppress certain warning types
 ODP_CFLAGS="$ODP_CFLAGS $ODP_CFLAGS_EXTRA"
 
-#
-# Check if compiler supports cmpxchng16
-##
-if test "${CC}" != "gcc" -o ${CC_VERSION_MAJOR} -ge 5; then
-   my_save_cflags="$CFLAGS"
-
-   CFLAGS=-mcx16
-   AC_MSG_CHECKING([whether CC supports -mcx16])
-   AC_COMPILE_IFELSE([AC_LANG_PROGRAM([])],
-   [AC_MSG_RESULT([yes])]
-   [ODP_CFLAGS="$ODP_CFLAGS $CFLAGS"],
-   [AC_MSG_RESULT([no])]
-   )
-   CFLAGS="$my_save_cflags"
+##
+# Check if compiler supports cmpxchng16 on x86-based architectures
+##
+if "${host}" == i?86* -o "${host}" == x86*; then
+  if test "${CC}" != "gcc" -o ${CC_VERSION_MAJOR} -ge 5; then
+ my_save_cflags="$CFLAGS"
+
+ CFLAGS=-mcx16
+ AC_MSG_CHECKING([whether CC supports -mcx16])
+ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([])],
+   [AC_MSG_RESULT([yes])]
+   [ODP_CFLAGS="$ODP_CFLAGS $CFLAGS"],
+   [AC_MSG_RESULT([no])]
+   )
+ CFLAGS="$my_save_cflags"
+  fi
 fi
 
 ##
-- 
2.12.2

Re: [lng-odp] [PATCH 1/2] add queue size param and related capability

[Bill Fischofer]

On Wed, Apr 12, 2017 at 12:28 PM, Honnappa Nagarahalli
 wrote:
> On 12 April 2017 at 00:45, Bala Manoharan  wrote:
>> Regards,
>> Bala
>>
>>
>> On 12 April 2017 at 10:05, Honnappa Nagarahalli
>>  wrote:
>>> On 11 April 2017 at 05:51, Bala Manoharan  wrote:
 On 10 April 2017 at 21:47, Honnappa Nagarahalli
  wrote:
> Hi Bala,
> Continuing the discussion from the call, as I mentioned in the
> call today, the queues need to hold all kinds of events and not just
> packets. The events need not be defined by ODP (like timeout events)
> also. The application may have its own events.
>
> In such a case, queue size does not dependent on the capacity of
> various pools supported in ODP. The size should depend on the
> implementation.

 ODP queues hold odp_event_t and these events needs to be allocated
 from a pool even in case of a timer.
>>>
>>> If I create a queue between two pipeline stages, the producer can
>>> produce any 64b data and typecast it to odp_event_t and store it in
>>> the queue. The consumer can dequeue from that queue and use that 64b
>>> data according to the need of the application. It need not be
>>> allocated from any pool.
>>
>> The idea of storing it in the queue is the concern there are
>> implementations where queue is a virtual
>> concept and even in the use-case you have defined the data has to be
>> allocated from a memory region
>> and the pointer is only handled by the queue in my implementation.
>> so even if I return 0 for the capability it does not mean there is
>> unlimited possibility,
>
> Agree. There is no true unlimited possibility. I am fine to change it
> to "Value of zero indicates the size is limited only by the available
> resources in the system at the time of creation."

Petri's argument earlier today to me seemed convincing that this is
not a useful piece of information for applications looking to check if
they have sufficient resources available to operate successfully. What
the application wants to know is "what is the minimum number of queues
this ODP instance is guaranteed to be able to create"?

Please see my earlier comments at
https://lists.linaro.org/pipermail/lng-odp/2017-April/029844.html

I'd appreciate your thoughts on this.

>
>> there is a hidden limitation
>> either by the pool or by any memory region.
>
> In a software implementation of the pools, the size of the pool is
> again dependent on the available resources in the system. The size of
> the queue need not depend on the pool size. Application should decide
> how that dependency should be - it might want to configure the pool
> size depending on the queue size capability or vice versa.
>
>>
>>>
>>> Also since in your case you are returning
 the maximum number of events across all the queues there needs to be a 
 valid
 use-case for this value.
>>>
>>> The capability API would return the maximum size of a queue that the
>>> application can create - if there is a fixed maximum queue size.
>>> Otherwise, it would return 0, indicating that the max size is not
>>> fixed - it is dependent on available resources at the time of
>>> creation. One could create 10 queues of size 1K elements, but there
>>> are not enough resources to create 11th queue with a size of 1K at
>>> that point in time.
>>>

 Regards,
 Bala

>
> If the queue is allocated out of memory, then the size should depend
> on the available amount of memory at any point in time.
>
> Thank you,
> Honnappa
>
> On 7 April 2017 at 02:54, Savolainen, Petri (Nokia - FI/Espoo)
>  wrote:
>> See my patch series: [PATCH v3 1/2] api: queue: added queue size param
>>
>>
>>> -Original Message-
>>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>>> Honnappa Nagarahalli
>>> Sent: Friday, April 07, 2017 7:07 AM
>>> To: lng-odp@lists.linaro.org
>>> Subject: [lng-odp] [PATCH 1/2] add queue size param and related 
>>> capability
>>>
>>> Added size parameter indicating the maximum number of events in the
>>> queue and the corresponding queue capability changes.
>>>
>>> Signed-off-by: Honnappa Nagarahalli 
>>> ---
>>>  include/odp/api/spec/queue.h   | 12 
>>>  platform/linux-generic/odp_queue.c |  1 +
>>>  2 files changed, 13 insertions(+)
>>>
>>> diff --git a/include/odp/api/spec/queue.h b/include/odp/api/spec/queue.h
>>> index 7972fea..ccb6fb8 100644
>>> --- a/include/odp/api/spec/queue.h
>>> +++ b/include/odp/api/spec/queue.h
>>> @@ -112,6 +112,12 @@ typedef struct odp_queue_capability_t {
>>>   /** Number of scheduling priorities */
>>>   unsigned sched_prios;

Re: [lng-odp] [PATCH 1/2] add queue size param and related capability

[Honnappa Nagarahalli]

On 12 April 2017 at 00:45, Bala Manoharan  wrote:
> Regards,
> Bala
>
>
> On 12 April 2017 at 10:05, Honnappa Nagarahalli
>  wrote:
>> On 11 April 2017 at 05:51, Bala Manoharan  wrote:
>>> On 10 April 2017 at 21:47, Honnappa Nagarahalli
>>>  wrote:
 Hi Bala,
 Continuing the discussion from the call, as I mentioned in the
 call today, the queues need to hold all kinds of events and not just
 packets. The events need not be defined by ODP (like timeout events)
 also. The application may have its own events.

 In such a case, queue size does not dependent on the capacity of
 various pools supported in ODP. The size should depend on the
 implementation.
>>>
>>> ODP queues hold odp_event_t and these events needs to be allocated
>>> from a pool even in case of a timer.
>>
>> If I create a queue between two pipeline stages, the producer can
>> produce any 64b data and typecast it to odp_event_t and store it in
>> the queue. The consumer can dequeue from that queue and use that 64b
>> data according to the need of the application. It need not be
>> allocated from any pool.
>
> The idea of storing it in the queue is the concern there are
> implementations where queue is a virtual
> concept and even in the use-case you have defined the data has to be
> allocated from a memory region
> and the pointer is only handled by the queue in my implementation.
> so even if I return 0 for the capability it does not mean there is
> unlimited possibility,

Agree. There is no true unlimited possibility. I am fine to change it
to "Value of zero indicates the size is limited only by the available
resources in the system at the time of creation."

> there is a hidden limitation
> either by the pool or by any memory region.

In a software implementation of the pools, the size of the pool is
again dependent on the available resources in the system. The size of
the queue need not depend on the pool size. Application should decide
how that dependency should be - it might want to configure the pool
size depending on the queue size capability or vice versa.

>
>>
>> Also since in your case you are returning
>>> the maximum number of events across all the queues there needs to be a valid
>>> use-case for this value.
>>
>> The capability API would return the maximum size of a queue that the
>> application can create - if there is a fixed maximum queue size.
>> Otherwise, it would return 0, indicating that the max size is not
>> fixed - it is dependent on available resources at the time of
>> creation. One could create 10 queues of size 1K elements, but there
>> are not enough resources to create 11th queue with a size of 1K at
>> that point in time.
>>
>>>
>>> Regards,
>>> Bala
>>>

 If the queue is allocated out of memory, then the size should depend
 on the available amount of memory at any point in time.

 Thank you,
 Honnappa

 On 7 April 2017 at 02:54, Savolainen, Petri (Nokia - FI/Espoo)
  wrote:
> See my patch series: [PATCH v3 1/2] api: queue: added queue size param
>
>
>> -Original Message-
>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>> Honnappa Nagarahalli
>> Sent: Friday, April 07, 2017 7:07 AM
>> To: lng-odp@lists.linaro.org
>> Subject: [lng-odp] [PATCH 1/2] add queue size param and related 
>> capability
>>
>> Added size parameter indicating the maximum number of events in the
>> queue and the corresponding queue capability changes.
>>
>> Signed-off-by: Honnappa Nagarahalli 
>> ---
>>  include/odp/api/spec/queue.h   | 12 
>>  platform/linux-generic/odp_queue.c |  1 +
>>  2 files changed, 13 insertions(+)
>>
>> diff --git a/include/odp/api/spec/queue.h b/include/odp/api/spec/queue.h
>> index 7972fea..ccb6fb8 100644
>> --- a/include/odp/api/spec/queue.h
>> +++ b/include/odp/api/spec/queue.h
>> @@ -112,6 +112,12 @@ typedef struct odp_queue_capability_t {
>>   /** Number of scheduling priorities */
>>   unsigned sched_prios;
>>
>> + /** Maximum number of events in the queue.
>> +   *
>> +   * Value of zero indicates the size is limited only by the
>> available
>> +   * memory in the system. */
>> + unsigned max_size;
>> +
>>  } odp_queue_capability_t;
>>
>>  /**
>> @@ -124,6 +130,12 @@ typedef struct odp_queue_param_t {
>> * the queue type. */
>>   odp_queue_type_t type;
>>
>> + /** Queue size
>> +   *
>> +   * Maximum number of events in the queue. Value of 0 chooses
>> the
>> +   * default configuration of the implementation. */
>> + uint32_t size;
>> +
>>  

Re: [lng-odp] [API-NEXT PATCH v2 0/4] Deprecated macros

[Bill Fischofer]

On Wed, Apr 12, 2017 at 10:05 AM, Dmitry Eremin-Solenikov
 wrote:
> On 12.04.2017 17:24, Bill Fischofer wrote:
>> On Wed, Apr 12, 2017 at 8:22 AM, Dmitry Eremin-Solenikov
>>  wrote:
>>> On 12.04.2017 15:21, Bill Fischofer wrote:
 On Wed, Apr 12, 2017 at 7:11 AM, Dmitry Eremin-Solenikov
  wrote:
> On 12.04.2017 14:50, Savolainen, Petri (Nokia - FI/Espoo) wrote:
>>
>>
>>> -Original Message-
>>> From: Dmitry Eremin-Solenikov [mailto:dmitry.ereminsoleni...@linaro.org]
>>> Sent: Wednesday, April 12, 2017 2:32 PM
>>> To: Petri Savolainen ; lng-
>>> o...@lists.linaro.org
>>> Subject: Re: [lng-odp] [API-NEXT PATCH v2 0/4] Deprecated macros
>>>
>>> On 30.03.2017 16:58, Petri Savolainen wrote:
 Replaced ODP_DEPRECATED macro (which was based on GCC __attribute__)
>>> with
 compiler independent mechanism to control if deprecated API definitions
>>> are
 visible to the application. ODP_DEPRECATED_API can be used both in
>>> application
 and implementation to check if deprecated APIs are enabled. By default
>>> those are
 disabled. Implementation may optimize the normal (new API) code path.

 ODP_DEPRECATE() macro is used to rename definitions, so that data
>>> structure
 sizes are equal on both options. This enables implementation to serve
>>> both
 options with a single library (if it wishes to do so).
>>>
>>> My main question remains as it was before: is it possible for the
>>> distribution to supply (unoptimized) ODP binary and headers and then for
>>> the application to select if it builds with or without deprecated API
>>> using that binary/headers?
>>
>>
>> Yes. This patch set keeps the same struct fields/etc for both modes - 
>> only the names are scrambled (with __deprecated_ prefix) when deprecated 
>> APIs are not supported (the default).
>
> If so. Consider I have built and installed ODP headers & binary built
> with --enable-deprecated-api.
>
> How do I build:
>
> - application that uses deprecated API?
>   [I assume that the answer to this question is trivial: just build as 
> is].
>
> - application that wants to be sure that it does not use deprecated API?

 As a practical matter, the support of deprecated APIs is similar to
 the current provision for debug builds (--enable-debug and
 --enable-debug-print in the current ./configure script). These really
 are only of significance in the embedded space.
>>>
>>> Or for application developers.
>>>
 In the cloud profile,
 applications use whatever ODP release(s) are installed on the system
 and the normal library-matchings are used to ensure that applications
 built for Release X are paired with library .so files compatible with
 that release. In this case, there are no deprecated APIs since
 applications only move to newer ODP release levels when they are
 ready. A cloud host system may specify the minimum ODP release level
 available on it, and that determines when laggards need to upgrade.
>>>
>>> Yep. That is the deployed ODP release. It is optimized for speed, it is
>>> optimized for that exact platform, etc. I'm more thinking about app
>>> developers.
>>>

 So ODP will never ship a distribution that was configured with
 --enable-deprecated-api. The only users of this feature will be
 embedded applications that are customizing ODP to their own needs.
>>>
>>> I'm thinking about SuSe, Canonical, RedHat or anybody else shipping ODP
>>> to enable application  development on that platform. They would surely
>>> want to enable deprecated API (because otherwise old applications
>>> developed on that platform can stop building). But I'd expect that it is
>>> possible for the application developer to build an application checking
>>> that he does not use deprecated API anymore.
>>
>> This is really no different than supporting multiple levels of, say,
>> the GCC compiler. Or any other package. At some point the old releases
>> are no longer supported, but for some time you can have multiple
>> levels available at the same time and you just use the one that you
>> need.
>
> We might want to consult maintainers. But from my previous experience,
> supporting several 'levels' is a significant headache, that most of
> maintainers would like to stand away from. Moreover, even if several
> versions are provided by distro, app developers still would like to have
> 'migration' path. Consider the way deprecated API are implemented e.g.
> in Gtk, Qt or other app frameworks.

The migration path is very straightforward: Don't move until you're
ready to move. When you are ready to move you change your application
to use the new preferred APIs.

Re: [lng-odp] [PATCH v3 1/2] api: queue: added queue size param

[Bill Fischofer]

Based on today's ARCH call, this seems to be a good approach, with
some slight wording clarification (noted below)

On Mon, Apr 3, 2017 at 5:11 AM, Petri Savolainen
 wrote:
> Added capability information about maximum number of queues
> and queue sizes. Both are defined per queue type, since
> plain and scheduled queues may have different implementations
> (e.g. one uses HW while the other is SW).
>
> Added queue size parameter, which specifies how large
> storage size application requires in minimum.
>
> Signed-off-by: Petri Savolainen 
> ---
>  include/odp/api/spec/queue.h | 35 ++-
>  1 file changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/include/odp/api/spec/queue.h b/include/odp/api/spec/queue.h
> index 7972fea..9c83322 100644
> --- a/include/odp/api/spec/queue.h
> +++ b/include/odp/api/spec/queue.h
> @@ -100,7 +100,9 @@ typedef enum odp_queue_op_mode_t {
>   * Queue capabilities
>   */
>  typedef struct odp_queue_capability_t {
> -   /** Maximum number of event queues */
> +   /** Maximum number of event queues of any type. Use this in addition 
> to
> + * queue type specific 'max_num', if both queue types are used
> + * simultaneously. */
> uint32_t max_queues;

These fields tell the application how many queues it is guaranteed to
be able to create, hence this is really a minimum number, not a
maximum number. An application may in fact be able to create more, but
it's guaranteed to be able to create at least this number. So I
suggest the following rename/rewording to clarify this point.

 /** Minimum guaranteed number of event queues of any
type. Use this in addition to
  * queue type specific 'min_num', if both queue types are
used simultaneously */
uint32_t min_queues;

>
> /** Maximum number of ordered locks per queue */
> @@ -112,6 +114,28 @@ typedef struct odp_queue_capability_t {
> /** Number of scheduling priorities */
> unsigned sched_prios;
>
> +   /** Plain queue capabilities */
> +   struct {
> +   /** Maximum number of a plain queues. */
> +   uint32_t max_num;

/** Minimum guaranteed number of plain queues that
may be created in this ODP instance */
uint32_t min_num;

> +
> +   /** Maximum number of events a plain queue can store
> + * simultaneously. The value of zero means unlimited. */
> +   uint32_t max_size;
> +
> +   } plain;
> +
> +   /** Scheduled queue capabilities */
> +   struct {
> +   /** Maximum number of a scheduled queues. */
> +   uint32_t max_num;

/** Minimum guaranteed number of scheduled queues
that may be created in this ODP instance */
uint32_t min_num;

> +
> +   /** Maximum number of events a scheduled queue can store
> + * simultaneously. The value of zero means unlimited. */
> +   uint32_t max_size;
> +
> +   } sched;
> +
>  } odp_queue_capability_t;
>
>  /**
> @@ -165,6 +189,15 @@ typedef struct odp_queue_param_t {
>   * The implementation may use this value as a hint for the number of
>   * context data bytes to prefetch. Default value is zero (no hint). 
> */
> uint32_t context_len;
> +
> +   /** Queue size
> + *
> + * The queue must be able to store at minimum this many events
> + * simultaneously. The value must not exceed 'max_size' queue
> + * capability. The value of zero means implementation specific
> + * default size. */
> +   uint32_t size;
> +
>  } odp_queue_param_t;
>
>  /**
> --
> 2.8.1
>

Re: [lng-odp] [PATCH v3] example: add IPv4 fragmentation/reassembly example

[Dmitry Eremin-Solenikov]

On 12.04.2017 17:24, Brian Brooks wrote:
> On Wed, Apr 12, 2017 at 8:24 AM, Dmitry Eremin-Solenikov
>  wrote:
>> On 12.04.2017 16:01, Joe Savage wrote:
>>> On 12/04/17 13:22, Dmitry Eremin-Solenikov wrote:
 On 12.04.2017 14:05, Joe Savage wrote:
> On 12/04/17 11:32, Maxim Uvarov wrote:
>> On 12.04.2017 13:15, Joe Savage wrote:
>> The problem is that when we discussed this patch on ODP call people 
>> very
>> worry about having 128bit instructions in ODP examples. At least 
>> Petri
>> and Barry asked if it would be possible to rewrite that with 64 bit
>> instructions? Some compilers might not support 128 bits and we need 
>> to
>> test it more.
>
> On 32-bit platforms, it already does use 64-bit atomics. In general, 
> though,
> the example hinges around having atomics that are twice the pointer 
> size.
> We've actually discussed this on the list already in the thread 
> "32-bit
> support in examples". Even if lock-free implementations can't be used,
> compilers can (and frequently do?) provide a lock-based compare 
> exchange
> operation.

 Any progress on this?
>>>
>>> This is getting mildly ridiculous now — it's nearing three months since 
>>> I
>>> initially submitted this simple example patch, and there's still no end 
>>> in
>>> sight! Maxim: any status updates?
>>>
>>
>> Dmitry wanted to write some big review for that patch. But I do not see
>> anything here. People commented on 128 bit instructions in examples and
>> nobody set their review-by. I will rise question about your patch one
>> more time on arch call. I can not include things where we did not get
>> common agreement. I do not see anything bad with this patch but we need
>> account all existence odp platforms.

 I'm sorry for the delay. Was quite under a pile of IPsec stuff...
>>>
>>> No worries.
>>>
 I'm quite not happy about intermixture of arch-dependent and
 arch-specific stuff in headers. Would it be possible to split
 arch-specific implementation details to per-arch headers (one for
 AArch64, one for older ARM and one generic) and include proper header
 based on the $(ARCH_DIR)? It would be especially nice to have such
 header provide ATOMIC_STRONG_CAS_DBLPTR (or maybe just
 atomic_strong_cas_dblptr() ).
>>>
>>> Sure, I can split apart the architecture dependent stuff if you'd prefer it
>>> that way. If I'm understanding you correctly, the suggestion here is to move
>>> the architecture-specific CAS implementations into separate files — each
>>> defining its own version of atomic_strong_cas_dblptr() — and for these 
>>> files to
>>> then be conditionally included in odp_ipfragreass_helpers.h. Is that right?
>>
>> Yes, that would be great!
>>
>>>
>>> I'm not sure I quite follow your comments regarding $(ARCH_DIR) though. Are
>>> there some ODP-defined macros that I can use instead of "__ARM_ARCH" and
>>> friends or something?
>>
>> You can have arm, arm64, mips64, etc. directories inside
>> examples/ipfrag.
> 
> This does not scale in practice. If another example comes along, does
> that also need to split whatever is determined to be "arch" code into
> "arch" directories within its own folder?
> 
> I recommend that this contribution be accepted without any further change.

>From my perspective, separate arm, aarch64 and generic headers would be
sufficient, even if they are not put under separate directories. That
was just a suggestion.

>> With smth. like odp_cas_dblptr.h header inside. Then
>> make _helpers.h include odp_case_dblptr.h, adding -I$(ARCH_DIR) to
>> CPPFLAGS in you example Makefile.
>>
>> --
>> With best wishes
>> Dmitry


-- 
With best wishes
Dmitry

Re: [lng-odp] [API-NEXT PATCH v2 0/4] Deprecated macros

[Dmitry Eremin-Solenikov]

On 12.04.2017 17:24, Bill Fischofer wrote:
> On Wed, Apr 12, 2017 at 8:22 AM, Dmitry Eremin-Solenikov
>  wrote:
>> On 12.04.2017 15:21, Bill Fischofer wrote:
>>> On Wed, Apr 12, 2017 at 7:11 AM, Dmitry Eremin-Solenikov
>>>  wrote:
 On 12.04.2017 14:50, Savolainen, Petri (Nokia - FI/Espoo) wrote:
>
>
>> -Original Message-
>> From: Dmitry Eremin-Solenikov [mailto:dmitry.ereminsoleni...@linaro.org]
>> Sent: Wednesday, April 12, 2017 2:32 PM
>> To: Petri Savolainen ; lng-
>> o...@lists.linaro.org
>> Subject: Re: [lng-odp] [API-NEXT PATCH v2 0/4] Deprecated macros
>>
>> On 30.03.2017 16:58, Petri Savolainen wrote:
>>> Replaced ODP_DEPRECATED macro (which was based on GCC __attribute__)
>> with
>>> compiler independent mechanism to control if deprecated API definitions
>> are
>>> visible to the application. ODP_DEPRECATED_API can be used both in
>> application
>>> and implementation to check if deprecated APIs are enabled. By default
>> those are
>>> disabled. Implementation may optimize the normal (new API) code path.
>>>
>>> ODP_DEPRECATE() macro is used to rename definitions, so that data
>> structure
>>> sizes are equal on both options. This enables implementation to serve
>> both
>>> options with a single library (if it wishes to do so).
>>
>> My main question remains as it was before: is it possible for the
>> distribution to supply (unoptimized) ODP binary and headers and then for
>> the application to select if it builds with or without deprecated API
>> using that binary/headers?
>
>
> Yes. This patch set keeps the same struct fields/etc for both modes - 
> only the names are scrambled (with __deprecated_ prefix) when deprecated 
> APIs are not supported (the default).

 If so. Consider I have built and installed ODP headers & binary built
 with --enable-deprecated-api.

 How do I build:

 - application that uses deprecated API?
   [I assume that the answer to this question is trivial: just build as is].

 - application that wants to be sure that it does not use deprecated API?
>>>
>>> As a practical matter, the support of deprecated APIs is similar to
>>> the current provision for debug builds (--enable-debug and
>>> --enable-debug-print in the current ./configure script). These really
>>> are only of significance in the embedded space.
>>
>> Or for application developers.
>>
>>> In the cloud profile,
>>> applications use whatever ODP release(s) are installed on the system
>>> and the normal library-matchings are used to ensure that applications
>>> built for Release X are paired with library .so files compatible with
>>> that release. In this case, there are no deprecated APIs since
>>> applications only move to newer ODP release levels when they are
>>> ready. A cloud host system may specify the minimum ODP release level
>>> available on it, and that determines when laggards need to upgrade.
>>
>> Yep. That is the deployed ODP release. It is optimized for speed, it is
>> optimized for that exact platform, etc. I'm more thinking about app
>> developers.
>>
>>>
>>> So ODP will never ship a distribution that was configured with
>>> --enable-deprecated-api. The only users of this feature will be
>>> embedded applications that are customizing ODP to their own needs.
>>
>> I'm thinking about SuSe, Canonical, RedHat or anybody else shipping ODP
>> to enable application  development on that platform. They would surely
>> want to enable deprecated API (because otherwise old applications
>> developed on that platform can stop building). But I'd expect that it is
>> possible for the application developer to build an application checking
>> that he does not use deprecated API anymore.
> 
> This is really no different than supporting multiple levels of, say,
> the GCC compiler. Or any other package. At some point the old releases
> are no longer supported, but for some time you can have multiple
> levels available at the same time and you just use the one that you
> need.

We might want to consult maintainers. But from my previous experience,
supporting several 'levels' is a significant headache, that most of
maintainers would like to stand away from. Moreover, even if several
versions are provided by distro, app developers still would like to have
'migration' path. Consider the way deprecated API are implemented e.g.
in Gtk, Qt or other app frameworks.

-- 
With best wishes
Dmitry

Re: [lng-odp] [API-NEXT PATCH 2/4] linux-gen: socket: handle recv/send calls with large burst size

[Bill Fischofer]

This patch seems orthogonal to the rest of this series. Shouldn't this
be a separate patch?

On Wed, Apr 12, 2017 at 7:58 AM, Matias Elo  wrote:
> There is no need to fail if the requested burst length is larger than the
> maximum supported. Simply use the maximum supported value instead.
>
> Signed-off-by: Matias Elo 
> ---
>  platform/linux-generic/pktio/socket.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/platform/linux-generic/pktio/socket.c 
> b/platform/linux-generic/pktio/socket.c
> index 89c6d46..e8b2e47 100644
> --- a/platform/linux-generic/pktio/socket.c
> +++ b/platform/linux-generic/pktio/socket.c
> @@ -628,7 +628,7 @@ static int sock_mmsg_recv(pktio_entry_t *pktio_entry, int 
> index ODP_UNUSED,
> int i;
>
> if (odp_unlikely(len > ODP_PACKET_SOCKET_MAX_BURST_RX))
> -   return -1;
> +   len = ODP_PACKET_SOCKET_MAX_BURST_RX;
>
> odp_ticketlock_lock(_entry->s.rxl);
>
> @@ -801,7 +801,7 @@ static int sock_mmsg_send(pktio_entry_t *pktio_entry, int 
> index ODP_UNUSED,
> int n, i;
>
> if (odp_unlikely(len > ODP_PACKET_SOCKET_MAX_BURST_TX))
> -   return -1;
> +   len = ODP_PACKET_SOCKET_MAX_BURST_TX;
>
> odp_ticketlock_lock(_entry->s.txl);
>
> --
> 2.7.4
>

[lng-odp] [Bug 2921] odp_init_global() and odp_pool_create() set errno = 12

[bugzilla-daemon]

https://bugs.linaro.org/show_bug.cgi?id=2921

--- Comment #5 from Oriol Arcas  ---
More info here:

https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=6619179

I can provide a patch for Monarch LTS, if you want.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: [lng-odp] [PATCH v3] example: add IPv4 fragmentation/reassembly example

[Brian Brooks]

On Wed, Apr 12, 2017 at 8:24 AM, Dmitry Eremin-Solenikov
 wrote:
> On 12.04.2017 16:01, Joe Savage wrote:
>> On 12/04/17 13:22, Dmitry Eremin-Solenikov wrote:
>>> On 12.04.2017 14:05, Joe Savage wrote:
 On 12/04/17 11:32, Maxim Uvarov wrote:
> On 12.04.2017 13:15, Joe Savage wrote:
> The problem is that when we discussed this patch on ODP call people 
> very
> worry about having 128bit instructions in ODP examples. At least Petri
> and Barry asked if it would be possible to rewrite that with 64 bit
> instructions? Some compilers might not support 128 bits and we need to
> test it more.

 On 32-bit platforms, it already does use 64-bit atomics. In general, 
 though,
 the example hinges around having atomics that are twice the pointer 
 size.
 We've actually discussed this on the list already in the thread "32-bit
 support in examples". Even if lock-free implementations can't be used,
 compilers can (and frequently do?) provide a lock-based compare 
 exchange
 operation.
>>>
>>> Any progress on this?
>>
>> This is getting mildly ridiculous now — it's nearing three months since I
>> initially submitted this simple example patch, and there's still no end 
>> in
>> sight! Maxim: any status updates?
>>
>
> Dmitry wanted to write some big review for that patch. But I do not see
> anything here. People commented on 128 bit instructions in examples and
> nobody set their review-by. I will rise question about your patch one
> more time on arch call. I can not include things where we did not get
> common agreement. I do not see anything bad with this patch but we need
> account all existence odp platforms.
>>>
>>> I'm sorry for the delay. Was quite under a pile of IPsec stuff...
>>
>> No worries.
>>
>>> I'm quite not happy about intermixture of arch-dependent and
>>> arch-specific stuff in headers. Would it be possible to split
>>> arch-specific implementation details to per-arch headers (one for
>>> AArch64, one for older ARM and one generic) and include proper header
>>> based on the $(ARCH_DIR)? It would be especially nice to have such
>>> header provide ATOMIC_STRONG_CAS_DBLPTR (or maybe just
>>> atomic_strong_cas_dblptr() ).
>>
>> Sure, I can split apart the architecture dependent stuff if you'd prefer it
>> that way. If I'm understanding you correctly, the suggestion here is to move
>> the architecture-specific CAS implementations into separate files — each
>> defining its own version of atomic_strong_cas_dblptr() — and for these files 
>> to
>> then be conditionally included in odp_ipfragreass_helpers.h. Is that right?
>
> Yes, that would be great!
>
>>
>> I'm not sure I quite follow your comments regarding $(ARCH_DIR) though. Are
>> there some ODP-defined macros that I can use instead of "__ARM_ARCH" and
>> friends or something?
>
> You can have arm, arm64, mips64, etc. directories inside
> examples/ipfrag.

This does not scale in practice. If another example comes along, does
that also need to split whatever is determined to be "arch" code into
"arch" directories within its own folder?

I recommend that this contribution be accepted without any further change.

> With smth. like odp_cas_dblptr.h header inside. Then
> make _helpers.h include odp_case_dblptr.h, adding -I$(ARCH_DIR) to
> CPPFLAGS in you example Makefile.
>
> --
> With best wishes
> Dmitry

Re: [lng-odp] [API-NEXT PATCH v2 0/4] Deprecated macros

[Bill Fischofer]

On Wed, Apr 12, 2017 at 8:22 AM, Dmitry Eremin-Solenikov
 wrote:
> On 12.04.2017 15:21, Bill Fischofer wrote:
>> On Wed, Apr 12, 2017 at 7:11 AM, Dmitry Eremin-Solenikov
>>  wrote:
>>> On 12.04.2017 14:50, Savolainen, Petri (Nokia - FI/Espoo) wrote:


> -Original Message-
> From: Dmitry Eremin-Solenikov [mailto:dmitry.ereminsoleni...@linaro.org]
> Sent: Wednesday, April 12, 2017 2:32 PM
> To: Petri Savolainen ; lng-
> o...@lists.linaro.org
> Subject: Re: [lng-odp] [API-NEXT PATCH v2 0/4] Deprecated macros
>
> On 30.03.2017 16:58, Petri Savolainen wrote:
>> Replaced ODP_DEPRECATED macro (which was based on GCC __attribute__)
> with
>> compiler independent mechanism to control if deprecated API definitions
> are
>> visible to the application. ODP_DEPRECATED_API can be used both in
> application
>> and implementation to check if deprecated APIs are enabled. By default
> those are
>> disabled. Implementation may optimize the normal (new API) code path.
>>
>> ODP_DEPRECATE() macro is used to rename definitions, so that data
> structure
>> sizes are equal on both options. This enables implementation to serve
> both
>> options with a single library (if it wishes to do so).
>
> My main question remains as it was before: is it possible for the
> distribution to supply (unoptimized) ODP binary and headers and then for
> the application to select if it builds with or without deprecated API
> using that binary/headers?


 Yes. This patch set keeps the same struct fields/etc for both modes - only 
 the names are scrambled (with __deprecated_ prefix) when deprecated APIs 
 are not supported (the default).
>>>
>>> If so. Consider I have built and installed ODP headers & binary built
>>> with --enable-deprecated-api.
>>>
>>> How do I build:
>>>
>>> - application that uses deprecated API?
>>>   [I assume that the answer to this question is trivial: just build as is].
>>>
>>> - application that wants to be sure that it does not use deprecated API?
>>
>> As a practical matter, the support of deprecated APIs is similar to
>> the current provision for debug builds (--enable-debug and
>> --enable-debug-print in the current ./configure script). These really
>> are only of significance in the embedded space.
>
> Or for application developers.
>
>> In the cloud profile,
>> applications use whatever ODP release(s) are installed on the system
>> and the normal library-matchings are used to ensure that applications
>> built for Release X are paired with library .so files compatible with
>> that release. In this case, there are no deprecated APIs since
>> applications only move to newer ODP release levels when they are
>> ready. A cloud host system may specify the minimum ODP release level
>> available on it, and that determines when laggards need to upgrade.
>
> Yep. That is the deployed ODP release. It is optimized for speed, it is
> optimized for that exact platform, etc. I'm more thinking about app
> developers.
>
>>
>> So ODP will never ship a distribution that was configured with
>> --enable-deprecated-api. The only users of this feature will be
>> embedded applications that are customizing ODP to their own needs.
>
> I'm thinking about SuSe, Canonical, RedHat or anybody else shipping ODP
> to enable application  development on that platform. They would surely
> want to enable deprecated API (because otherwise old applications
> developed on that platform can stop building). But I'd expect that it is
> possible for the application developer to build an application checking
> that he does not use deprecated API anymore.

This is really no different than supporting multiple levels of, say,
the GCC compiler. Or any other package. At some point the old releases
are no longer supported, but for some time you can have multiple
levels available at the same time and you just use the one that you
need.

>
>
>
> --
> With best wishes
> Dmitry

Re: [lng-odp] [PATCH v3] example: add IPv4 fragmentation/reassembly example

[Joe Savage]

On 12/04/17 14:44, Dmitry Eremin-Solenikov wrote:
> On 12.04.2017 16:37, Joe Savage wrote:
>> On 12/04/17 14:24, Dmitry Eremin-Solenikov wrote:
>>> On 12.04.2017 16:01, Joe Savage wrote:
 I'm not sure I quite follow your comments regarding $(ARCH_DIR) though. Are
 there some ODP-defined macros that I can use instead of "__ARM_ARCH" and
 friends or something?
>>>
>>> You can have arm, arm64, mips64, etc. directories inside
>>> examples/ipfrag. With smth. like odp_cas_dblptr.h header inside. Then
>>> make _helpers.h include odp_case_dblptr.h, adding -I$(ARCH_DIR) to
>>> CPPFLAGS in you example Makefile.
>>
>> Ah, I see. That's a really nice idea. I'm not sure it would quite give the
>> accuracy I need here though — it seems like "arm64" isn't an auto-detected
>> $(ARCH_DIR) option out of the box, and there isn't any way to single out 
>> ARMv7
>> dependent stuff specifically either.
>
> See below.
>
>> Also, I'm not sure how a generic fallback
>> would best be established in a system like that.
>
> You can have generic/dblptr.h . Then mips/ppc/x86 would just include
> that header.
>
> Inside arm/dblptr.h you can the following code:
>
> #if ARMv7
>
> void atomic_cas_dblptr()
> {
> }
>
> #else
> #include "generic/dblptr.h"
> #endif

Yeah, that would work. It seems a bit fragile to enumerate every known
ARCH_DIR (e.g. what if another architecture gets added), but I'll roll
with it if this is the preferred way to do things.

Re: [lng-odp] [PATCH v3] example: add IPv4 fragmentation/reassembly example

[Dmitry Eremin-Solenikov]

On 12.04.2017 16:37, Joe Savage wrote:
> On 12/04/17 14:24, Dmitry Eremin-Solenikov wrote:
>> On 12.04.2017 16:01, Joe Savage wrote:
>>> I'm not sure I quite follow your comments regarding $(ARCH_DIR) though. Are
>>> there some ODP-defined macros that I can use instead of "__ARM_ARCH" and
>>> friends or something?
>>
>> You can have arm, arm64, mips64, etc. directories inside
>> examples/ipfrag. With smth. like odp_cas_dblptr.h header inside. Then
>> make _helpers.h include odp_case_dblptr.h, adding -I$(ARCH_DIR) to
>> CPPFLAGS in you example Makefile.
> 
> Ah, I see. That's a really nice idea. I'm not sure it would quite give the
> accuracy I need here though — it seems like "arm64" isn't an auto-detected
> $(ARCH_DIR) option out of the box, and there isn't any way to single out ARMv7
> dependent stuff specifically either.

See below.

> Also, I'm not sure how a generic fallback
> would best be established in a system like that.

You can have generic/dblptr.h . Then mips/ppc/x86 would just include
that header.

Inside arm/dblptr.h you can the following code:

#if ARMv7

void atomic_cas_dblptr()
{
}

#else
#include "generic/dblptr.h"
#endif

> For the time being, I'll split the architecture-dependent stuff into separate
> header files and then simply conditionally include these based on the same
> macros I'm using at the moment (__ARM_ARCH, etc.). Would that be alright?
> 


-- 
With best wishes
Dmitry

Re: [lng-odp] [PATCH v3] example: add IPv4 fragmentation/reassembly example

[Joe Savage]

On 12/04/17 14:24, Dmitry Eremin-Solenikov wrote:
> On 12.04.2017 16:01, Joe Savage wrote:
>> I'm not sure I quite follow your comments regarding $(ARCH_DIR) though. Are
>> there some ODP-defined macros that I can use instead of "__ARM_ARCH" and
>> friends or something?
>
> You can have arm, arm64, mips64, etc. directories inside
> examples/ipfrag. With smth. like odp_cas_dblptr.h header inside. Then
> make _helpers.h include odp_case_dblptr.h, adding -I$(ARCH_DIR) to
> CPPFLAGS in you example Makefile.

Ah, I see. That's a really nice idea. I'm not sure it would quite give the
accuracy I need here though — it seems like "arm64" isn't an auto-detected
$(ARCH_DIR) option out of the box, and there isn't any way to single out ARMv7
dependent stuff specifically either. Also, I'm not sure how a generic fallback
would best be established in a system like that.

For the time being, I'll split the architecture-dependent stuff into separate
header files and then simply conditionally include these based on the same
macros I'm using at the moment (__ARM_ARCH, etc.). Would that be alright?

Re: [lng-odp] [PATCH v3] example: add IPv4 fragmentation/reassembly example

[Dmitry Eremin-Solenikov]

On 12.04.2017 16:01, Joe Savage wrote:
> On 12/04/17 13:22, Dmitry Eremin-Solenikov wrote:
>> On 12.04.2017 14:05, Joe Savage wrote:
>>> On 12/04/17 11:32, Maxim Uvarov wrote:
 On 12.04.2017 13:15, Joe Savage wrote:
 The problem is that when we discussed this patch on ODP call people 
 very
 worry about having 128bit instructions in ODP examples. At least Petri
 and Barry asked if it would be possible to rewrite that with 64 bit
 instructions? Some compilers might not support 128 bits and we need to
 test it more.
>>>
>>> On 32-bit platforms, it already does use 64-bit atomics. In general, 
>>> though,
>>> the example hinges around having atomics that are twice the pointer 
>>> size.
>>> We've actually discussed this on the list already in the thread "32-bit
>>> support in examples". Even if lock-free implementations can't be used,
>>> compilers can (and frequently do?) provide a lock-based compare exchange
>>> operation.
>>
>> Any progress on this?
>
> This is getting mildly ridiculous now — it's nearing three months since I
> initially submitted this simple example patch, and there's still no end in
> sight! Maxim: any status updates?
>

 Dmitry wanted to write some big review for that patch. But I do not see
 anything here. People commented on 128 bit instructions in examples and
 nobody set their review-by. I will rise question about your patch one
 more time on arch call. I can not include things where we did not get
 common agreement. I do not see anything bad with this patch but we need
 account all existence odp platforms.
>>
>> I'm sorry for the delay. Was quite under a pile of IPsec stuff...
> 
> No worries.
> 
>> I'm quite not happy about intermixture of arch-dependent and
>> arch-specific stuff in headers. Would it be possible to split
>> arch-specific implementation details to per-arch headers (one for
>> AArch64, one for older ARM and one generic) and include proper header
>> based on the $(ARCH_DIR)? It would be especially nice to have such
>> header provide ATOMIC_STRONG_CAS_DBLPTR (or maybe just
>> atomic_strong_cas_dblptr() ).
> 
> Sure, I can split apart the architecture dependent stuff if you'd prefer it
> that way. If I'm understanding you correctly, the suggestion here is to move
> the architecture-specific CAS implementations into separate files — each
> defining its own version of atomic_strong_cas_dblptr() — and for these files 
> to
> then be conditionally included in odp_ipfragreass_helpers.h. Is that right?

Yes, that would be great!

> 
> I'm not sure I quite follow your comments regarding $(ARCH_DIR) though. Are
> there some ODP-defined macros that I can use instead of "__ARM_ARCH" and
> friends or something?

You can have arm, arm64, mips64, etc. directories inside
examples/ipfrag. With smth. like odp_cas_dblptr.h header inside. Then
make _helpers.h include odp_case_dblptr.h, adding -I$(ARCH_DIR) to
CPPFLAGS in you example Makefile.

-- 
With best wishes
Dmitry

Re: [lng-odp] [PATCH v3] example: add IPv4 fragmentation/reassembly example

[Joe Savage]

On 12/04/17 13:22, Dmitry Eremin-Solenikov wrote:
> On 12.04.2017 14:05, Joe Savage wrote:
>> On 12/04/17 11:32, Maxim Uvarov wrote:
>>> On 12.04.2017 13:15, Joe Savage wrote:
>>> The problem is that when we discussed this patch on ODP call people very
>>> worry about having 128bit instructions in ODP examples. At least Petri
>>> and Barry asked if it would be possible to rewrite that with 64 bit
>>> instructions? Some compilers might not support 128 bits and we need to
>>> test it more.
>>
>> On 32-bit platforms, it already does use 64-bit atomics. In general, 
>> though,
>> the example hinges around having atomics that are twice the pointer size.
>> We've actually discussed this on the list already in the thread "32-bit
>> support in examples". Even if lock-free implementations can't be used,
>> compilers can (and frequently do?) provide a lock-based compare exchange
>> operation.
>
> Any progress on this?

 This is getting mildly ridiculous now — it's nearing three months since I
 initially submitted this simple example patch, and there's still no end in
 sight! Maxim: any status updates?

>>>
>>> Dmitry wanted to write some big review for that patch. But I do not see
>>> anything here. People commented on 128 bit instructions in examples and
>>> nobody set their review-by. I will rise question about your patch one
>>> more time on arch call. I can not include things where we did not get
>>> common agreement. I do not see anything bad with this patch but we need
>>> account all existence odp platforms.
>
> I'm sorry for the delay. Was quite under a pile of IPsec stuff...

No worries.

> I'm quite not happy about intermixture of arch-dependent and
> arch-specific stuff in headers. Would it be possible to split
> arch-specific implementation details to per-arch headers (one for
> AArch64, one for older ARM and one generic) and include proper header
> based on the $(ARCH_DIR)? It would be especially nice to have such
> header provide ATOMIC_STRONG_CAS_DBLPTR (or maybe just
> atomic_strong_cas_dblptr() ).

Sure, I can split apart the architecture dependent stuff if you'd prefer it
that way. If I'm understanding you correctly, the suggestion here is to move
the architecture-specific CAS implementations into separate files — each
defining its own version of atomic_strong_cas_dblptr() — and for these files to
then be conditionally included in odp_ipfragreass_helpers.h. Is that right?

I'm not sure I quite follow your comments regarding $(ARCH_DIR) though. Are
there some ODP-defined macros that I can use instead of "__ARM_ARCH" and
friends or something?

> Forgot to mention. Your implementation seems build fine for MIPS64, so
> there should be no more issues from my side.

Cool, good stuff.

[lng-odp] [API-NEXT PATCH 3/4] linux-gen: pool: add new maximum packet count fields to pool info

[Matias Elo]

Fill new odp_pool_info_t fields when calling odp_pool_info().

Also make sure that enough ring slots are allocated in pool_create() in a
case that the requested length packets (odp_pool_param_t.pkt.len) will be
segmented.

Signed-off-by: Matias Elo 
---
 .../linux-generic/include/odp_packet_internal.h| 22 ++
 platform/linux-generic/include/odp_pool_internal.h |  1 +
 platform/linux-generic/odp_packet.c| 22 --
 platform/linux-generic/odp_pool.c  | 21 ++---
 4 files changed, 41 insertions(+), 25 deletions(-)

diff --git a/platform/linux-generic/include/odp_packet_internal.h 
b/platform/linux-generic/include/odp_packet_internal.h
index d0db700..a6b4052 100644
--- a/platform/linux-generic/include/odp_packet_internal.h
+++ b/platform/linux-generic/include/odp_packet_internal.h
@@ -237,6 +237,28 @@ int packet_parse_common(packet_parser_t *pkt_hdr, const 
uint8_t *ptr,
 
 int _odp_cls_parse(odp_packet_hdr_t *pkt_hdr, const uint8_t *parseptr);
 
+/* Calculate the number of segments */
+static inline int num_segments(uint32_t len)
+{
+   uint32_t max_seg_len;
+   int num;
+
+   if (CONFIG_PACKET_MAX_SEGS == 1)
+   return 1;
+
+   num = 1;
+   max_seg_len = CONFIG_PACKET_MAX_SEG_LEN;
+
+   if (odp_unlikely(len > max_seg_len)) {
+   num = len / max_seg_len;
+
+   if (odp_likely((num * max_seg_len) != len))
+   num += 1;
+   }
+
+   return num;
+}
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/platform/linux-generic/include/odp_pool_internal.h 
b/platform/linux-generic/include/odp_pool_internal.h
index ebb779d..89be862 100644
--- a/platform/linux-generic/include/odp_pool_internal.h
+++ b/platform/linux-generic/include/odp_pool_internal.h
@@ -55,6 +55,7 @@ typedef struct pool_t {
odp_shm_tuarea_shm;
int  reserved;
uint32_t num;
+   uint32_t num_max_len;
uint32_t align;
uint32_t headroom;
uint32_t tailroom;
diff --git a/platform/linux-generic/odp_packet.c 
b/platform/linux-generic/odp_packet.c
index 0b70c5c..79a25d1 100644
--- a/platform/linux-generic/odp_packet.c
+++ b/platform/linux-generic/odp_packet.c
@@ -298,28 +298,6 @@ static inline void init_segments(odp_packet_hdr_t 
*pkt_hdr[], int num)
}
 }
 
-/* Calculate the number of segments */
-static inline int num_segments(uint32_t len)
-{
-   uint32_t max_seg_len;
-   int num;
-
-   if (CONFIG_PACKET_MAX_SEGS == 1)
-   return 1;
-
-   num = 1;
-   max_seg_len = CONFIG_PACKET_MAX_SEG_LEN;
-
-   if (odp_unlikely(len > max_seg_len)) {
-   num = len / max_seg_len;
-
-   if (odp_likely((num * max_seg_len) != len))
-   num += 1;
-   }
-
-   return num;
-}
-
 static inline void add_all_segs(odp_packet_hdr_t *to, odp_packet_hdr_t *from)
 {
int i;
diff --git a/platform/linux-generic/odp_pool.c 
b/platform/linux-generic/odp_pool.c
index 9dba734..6f732ce 100644
--- a/platform/linux-generic/odp_pool.c
+++ b/platform/linux-generic/odp_pool.c
@@ -293,6 +293,7 @@ static odp_pool_t pool_create(const char *name, 
odp_pool_param_t *params,
uint32_t max_len, max_seg_len;
uint32_t ring_size;
int name_len;
+   int num_max_len;
const char *postfix = "_uarea";
char uarea_name[ODP_POOL_NAME_LEN + sizeof(postfix)];
 
@@ -321,6 +322,7 @@ static odp_pool_t pool_create(const char *name, 
odp_pool_param_t *params,
data_size   = 0;
max_len = 0;
max_seg_len = 0;
+   num_max_len = 0;
uarea_size  = 0;
 
switch (params->type) {
@@ -332,11 +334,17 @@ static odp_pool_t pool_create(const char *name, 
odp_pool_param_t *params,
case ODP_POOL_PACKET:
headroom= CONFIG_PACKET_HEADROOM;
tailroom= CONFIG_PACKET_TAILROOM;
-   num = params->pkt.num;
+
+   num = params->pkt.num * num_segments(params->pkt.len);
+
+   max_seg_len = CONFIG_PACKET_MAX_SEG_LEN;
+   max_len = (params->pkt.max_len != 0) ? params->pkt.max_len :
+   CONFIG_PACKET_MAX_SEGS * max_seg_len;
+
+   num_max_len = num / num_segments(max_len);
+
uarea_size  = params->pkt.uarea_size;
data_size   = CONFIG_PACKET_MAX_SEG_LEN;
-   max_seg_len = CONFIG_PACKET_MAX_SEG_LEN;
-   max_len = CONFIG_PACKET_MAX_SEGS * max_seg_len;
break;
 
case ODP_POOL_TIMEOUT:
@@ -385,6 +393,7 @@ static odp_pool_t pool_create(const char *name, 
odp_pool_param_t *params,
 
pool->ring_mask  = ring_size - 1;
pool->num= num;
+   pool->num_max_len= num_max_len;
pool->align  = align;

[lng-odp] [API-NEXT PATCH 2/4] linux-gen: socket: handle recv/send calls with large burst size

[Matias Elo]

There is no need to fail if the requested burst length is larger than the
maximum supported. Simply use the maximum supported value instead.

Signed-off-by: Matias Elo 
---
 platform/linux-generic/pktio/socket.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/platform/linux-generic/pktio/socket.c 
b/platform/linux-generic/pktio/socket.c
index 89c6d46..e8b2e47 100644
--- a/platform/linux-generic/pktio/socket.c
+++ b/platform/linux-generic/pktio/socket.c
@@ -628,7 +628,7 @@ static int sock_mmsg_recv(pktio_entry_t *pktio_entry, int 
index ODP_UNUSED,
int i;
 
if (odp_unlikely(len > ODP_PACKET_SOCKET_MAX_BURST_RX))
-   return -1;
+   len = ODP_PACKET_SOCKET_MAX_BURST_RX;
 
odp_ticketlock_lock(_entry->s.rxl);
 
@@ -801,7 +801,7 @@ static int sock_mmsg_send(pktio_entry_t *pktio_entry, int 
index ODP_UNUSED,
int n, i;
 
if (odp_unlikely(len > ODP_PACKET_SOCKET_MAX_BURST_TX))
-   return -1;
+   len = ODP_PACKET_SOCKET_MAX_BURST_TX;
 
odp_ticketlock_lock(_entry->s.txl);
 
-- 
2.7.4

[lng-odp] [API-NEXT PATCH 1/4] api: pool: add maximum packet counts to pool info

[Matias Elo]

Add fields to odp_pool_info_t for maximum number of packets of any length,
maximum number of minimum length packets, and maximum number of maximum
length packets.

odp_pool_param_t documentation is updated to reflect these new fields.

Signed-off-by: Matias Elo 
---
 include/odp/api/spec/pool.h | 43 ++-
 1 file changed, 30 insertions(+), 13 deletions(-)

diff --git a/include/odp/api/spec/pool.h b/include/odp/api/spec/pool.h
index c0de195..402c9f2 100644
--- a/include/odp/api/spec/pool.h
+++ b/include/odp/api/spec/pool.h
@@ -181,23 +181,27 @@ typedef struct odp_pool_param_t {
uint32_t align;
} buf;
struct {
-   /** The number of packets that the pool must provide
-   that are packet length 'len' bytes or smaller.
-   The maximum value is defined by pool capability
-   pkt.max_num. */
+   /** The exact number of 'len' byte packets that the pool
+   must provide. The maximum value is defined by pool
+   capability pkt.max_num. Pool is empty after
+   allocating all the 'len' byte packets. Pool capacity
+   for other packet lengths may vary. See
+   odp_pool_info_t for details. */
uint32_t num;
 
-   /** Minimum packet length that the pool must provide
-   'num' packets. The number of packets may be less
-   than 'num' when packets are larger than 'len'.
-   The maximum value is defined by pool capability
-   pkt.max_len. Use 0 for default. */
+   /** The packet length that the pool must provide exactly
+   'num' packets. The maximum value is defined by pool
+   capability pkt.max_len. Pool capacity for other
+   packet lengths may vary. See odp_pool_info_t for
+   details. Use 0 for default. */
uint32_t len;
 
/** Maximum packet length that will be allocated from
the pool. The maximum value is defined by pool
-   capability pkt.max_len. Use 0 for default (the
-   pool maximum). */
+   capability pkt.max_len. Pool capacity for this
+   packet length can be checked from pool info
+   num_max_len (odp_pool_info_t). Use 0 for default
+   (the pool maximum).*/
uint32_t max_len;
 
/** Minimum number of packet data bytes that are stored
@@ -272,8 +276,21 @@ odp_pool_t odp_pool_lookup(const char *name);
  * Used to get information about a pool.
  */
 typedef struct odp_pool_info_t {
-   const char *name;  /**< pool name */
-   odp_pool_param_t params;   /**< pool parameters */
+   /** Pool name */
+   const char *name;
+   /** Pool parameters */
+   odp_pool_param_t params;
+   /** Packet pool info */
+   struct {
+   /** Maximum number of packets of any length */
+   uint32_t max_num;
+
+   /** Maximum number of minimum length packets */
+   uint32_t num_min_len;
+
+   /** Maximum number of maximum length packets */
+   uint32_t num_max_len;
+   } pkt;
 } odp_pool_info_t;
 
 /**
-- 
2.7.4

[lng-odp] [API-NEXT PATCH 0/4] add maximum packet counts to pool info

[Matias Elo]

On some packet pool implementations the number of available packets may vary
depending on the packet length (examples below). E.g. a packet pool may include
smaller sub-pools for different packet length ranges.

Num. pkts
A
|___
|   |
|   |___
|   |
|Pool 1 |___
|   |
|___|__>
0  51210242048 
Pkt length (B)

Num. pkts
A
|___
|   |   |
|   |   |
|___|Pool 2 |___
|   |
|___|__>
0  51210242048
Pkt length (B)

To better describe this kind of pools, add fields to odp_pool_info_t for maximum
number of packets of any length, maximum number of minimum length packets, and
maximum number of maximum length packets.

odp_pool_param_t documentation is updated to reflect these new fields.

Small fix is required to the socket pktio to make the validation suite pass.

Matias Elo (4):
  api: pool: add maximum packet counts to pool info
  linux-gen: socket: handle recv/send calls with large burst size
  linux-gen: pool: add new maximum packet count fields to pool info
  validation: pool: add tests for new odp_pool_info_t fields

 include/odp/api/spec/pool.h| 43 +++---
 .../linux-generic/include/odp_packet_internal.h| 22 +++
 platform/linux-generic/include/odp_pool_internal.h |  1 +
 platform/linux-generic/odp_packet.c| 22 ---
 platform/linux-generic/odp_pool.c  | 21 +--
 platform/linux-generic/pktio/socket.c  |  4 +-
 test/common_plat/validation/api/pool/pool.c| 20 ++
 7 files changed, 93 insertions(+), 40 deletions(-)

-- 
2.7.4

[lng-odp] [PATCH] examples: generator: UDP ports config

[Bogdan Pricope]

Add command line options to configure UDP ports for generated traffic.

Bogdan Pricope (1):
  examples: generator: UDP ports configuration

 example/generator/odp_generator.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

-- 
1.9.1

[lng-odp] [PATCH] examples: generator: UDP ports configuration

[Bogdan Pricope]

Signed-off-by: Bogdan Pricope 
---
 example/generator/odp_generator.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/example/generator/odp_generator.c 
b/example/generator/odp_generator.c
index 95fb543..4817294 100644
--- a/example/generator/odp_generator.c
+++ b/example/generator/odp_generator.c
@@ -64,6 +64,8 @@ typedef struct {
odph_ethaddr_t dstmac;  /**< dest mac addr */
unsigned int srcip; /**< src ip addr */
unsigned int dstip; /**< dest ip addr */
+   unsigned short srcport; /**< src udp port */
+   unsigned short dstport; /**< dest udp port */
int mode;   /**< work mode */
int number; /**< packets number to be sent */
int payload;/**< data len */
@@ -233,8 +235,8 @@ static odp_packet_t setup_udp_pkt_ref(odp_pool_t pool)
odp_packet_l4_offset_set(pkt, ODPH_ETHHDR_LEN + ODPH_IPV4HDR_LEN);
odp_packet_has_udp_set(pkt, 1);
udp = (odph_udphdr_t *)(buf + ODPH_ETHHDR_LEN + ODPH_IPV4HDR_LEN);
-   udp->src_port = 0;
-   udp->dst_port = 0;
+   udp->src_port = odp_cpu_to_be_16(args->appl.srcport);
+   udp->dst_port = odp_cpu_to_be_16(args->appl.dstport);
udp->length = odp_cpu_to_be_16(args->appl.payload + ODPH_UDPHDR_LEN);
udp->chksum = 0;
udp->chksum = odph_ipv4_udp_chksum(pkt);
@@ -1140,6 +1142,8 @@ static void parse_args(int argc, char *argv[], 
appl_args_t *appl_args)
{"dstmac", required_argument, NULL, 'b'},
{"srcip", required_argument, NULL, 's'},
{"dstip", required_argument, NULL, 'd'},
+   {"srcport", required_argument, NULL, 'e'},
+   {"dstport", required_argument, NULL, 'f'},
{"packetsize", required_argument, NULL, 'p'},
{"mode", required_argument, NULL, 'm'},
{"count", required_argument, NULL, 'n'},
@@ -1150,7 +1154,7 @@ static void parse_args(int argc, char *argv[], 
appl_args_t *appl_args)
{NULL, 0, NULL, 0}
};
 
-   static const char *shortopts = "+I:a:b:s:d:p:i:m:n:t:w:c:x:h";
+   static const char *shortopts = "+I:a:b:s:d:p:i:m:n:t:w:c:x:he:f:";
 
/* let helper collect its own arguments (e.g. --odph_proc) */
odph_parse_options(argc, argv, shortopts, longopts);
@@ -1161,6 +1165,8 @@ static void parse_args(int argc, char *argv[], 
appl_args_t *appl_args)
appl_args->timeout = -1;
appl_args->interval = DEFAULT_PKT_INTERVAL;
appl_args->udp_tx_burst = 16;
+   appl_args->srcport = 0;
+   appl_args->dstport = 0;
 
opterr = 0; /* do not issue errors on helper options */
 
@@ -1267,6 +1273,12 @@ static void parse_args(int argc, char *argv[], 
appl_args_t *appl_args)
}
break;
 
+   case 'e':
+   appl_args->srcport = (unsigned short)atoi(optarg);
+   break;
+   case 'f':
+   appl_args->dstport = (unsigned short)atoi(optarg);
+   break;
case 'p':
appl_args->payload = atoi(optarg);
break;
@@ -1380,6 +1392,8 @@ static void usage(char *progname)
   "\n"
   "Optional OPTIONS\n"
   "  -h, --help   Display help and exit.\n"
+  "  -e, --srcport src udp port\n"
+  "  -f, --dstport dst udp port\n"
   "  -p, --packetsize payload length of the packets\n"
   "  -t, --timeout only for ping mode, wait ICMP reply timeout 
seconds\n"
   "  -i, --interval wait interval ms between sending each packet\n"
-- 
1.9.1

Re: [lng-odp] [PATCH v3] example: add IPv4 fragmentation/reassembly example

[Joe Savage]

On 12/04/17 13:24, Dmitry Eremin-Solenikov wrote:
> On 10.02.2017 19:06, Joe Savage wrote:
>> +#ifndef ODP_FRAGREASS_PP_ATOMICS_H_
>> +#define ODP_FRAGREASS_PP_ATOMICS_H_
>> +
>> +#include 
>> +
>> +#if defined(__arm__) || defined(__aarch64__)
>> +#if defined(__aarch64__)
>> +static inline __int128 lld(__int128 *var, int mo);
>> +static inline uint32_t scd(__int128 *var, __int128 neu, int mo);
>
> Is there any reason to have prototypes, then main function, then lld/scd
> implementation? What about moving lld/scd upwards, so that there would
> be no extra prototypes?

Good point, I'll change this — thanks.

Re: [lng-odp] [PATCH 1/2] add queue size param and related capability

[Bill Fischofer]

On Tue, Apr 11, 2017 at 11:14 PM, Honnappa Nagarahalli
 wrote:
> On 10 April 2017 at 11:49, Bill Fischofer  wrote:
>> On Mon, Apr 10, 2017 at 11:17 AM, Honnappa Nagarahalli
>>  wrote:
>>> Hi Bala,
>>> Continuing the discussion from the call, as I mentioned in the
>>> call today, the queues need to hold all kinds of events and not just
>>> packets. The events need not be defined by ODP (like timeout events)
>>> also. The application may have its own events.
>>>
>>> In such a case, queue size does not dependent on the capacity of
>>> various pools supported in ODP. The size should depend on the
>>> implementation.
>>>
>>> If the queue is allocated out of memory, then the size should depend
>>> on the available amount of memory at any point in time.
>>
>> The real distinction is whether the implementation imposes a fixed
>> upper bound to queue size. This may be, for example, because queues
>> are implemented in hardware and there are hardware-imposed limits to
>> queue size. Or it may be that the implementation preallocates
>> resources at configuration time and these have fixed numbers
>> associated with them.
>>
>> ODP got along just fine before without having known queue sizes, so
>> the question is "what new information does the application want here"?
>> The only use-case we seem to have identified is the application
>> intends to use a queue as a storage mechanism and it wants to ensure
>> that the queue has a minimum storage capacity at queue create time. In
>> this case, the capability is reporting whether there is a fixed upper
>> bound that the application can use to compare to its minimum
>> requirements. If the answer is "yes", then the application can adjust
>> its needs (or refuse to run) based on that answer. If the answer is
>> "no" (a returned 0 as max_size) then the application can specify it's
>> requested size as input to odp_queue_create() and observe whether the
>> request succeeds or fails.
>>
>> The alternative is to not add a max_size to odp_queue_capability() at
>> all and simply let odp_queue_create() report success or failure in
>> response to a requested size. That's effectively what we have today,
>> except that by default the requested "size" is forced to 0, meaning
>> that the implementation chooses what, if any, such limits exist. The
>> only way these limits are surfaced to applications is if
>> odp_queue_enq() fails because the queue is full and the implementation
>> doesn't use back pressure. If back pressure is used, then the
>> odp_queue_enq() call simply stalls until room is made available in the
>> queue to satisfy the request.
>
> I prefer to leave the back pressure implementation to the application.
> This allows the application to have different algorithms to wait till
> the queue has space. For ex: on ARM platforms, the implementation can
> use WFE/SEV.

Back pressure is normally an implementation area because it is a
feature of hardware. If we expect applications to use
platform-specific features to implement this themselves, then this
defeats the portability goal of ODP. If the implementation doesn't use
back pressure, then odp_queue_enq() will fail when a queue is full and
applications can take whatever recovery action is appropriate, same as
the would on an allocation failure.

>
>>
>>>
>>> Thank you,
>>> Honnappa
>>>
>>> On 7 April 2017 at 02:54, Savolainen, Petri (Nokia - FI/Espoo)
>>>  wrote:
 See my patch series: [PATCH v3 1/2] api: queue: added queue size param


> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> Honnappa Nagarahalli
> Sent: Friday, April 07, 2017 7:07 AM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCH 1/2] add queue size param and related capability
>
> Added size parameter indicating the maximum number of events in the
> queue and the corresponding queue capability changes.
>
> Signed-off-by: Honnappa Nagarahalli 
> ---
>  include/odp/api/spec/queue.h   | 12 
>  platform/linux-generic/odp_queue.c |  1 +
>  2 files changed, 13 insertions(+)
>
> diff --git a/include/odp/api/spec/queue.h b/include/odp/api/spec/queue.h
> index 7972fea..ccb6fb8 100644
> --- a/include/odp/api/spec/queue.h
> +++ b/include/odp/api/spec/queue.h
> @@ -112,6 +112,12 @@ typedef struct odp_queue_capability_t {
>   /** Number of scheduling priorities */
>   unsigned sched_prios;
>
> + /** Maximum number of events in the queue.
> +   *
> +   * Value of zero indicates the size is limited only by the
> available
> +   * memory in the system. */
> + unsigned max_size;
> +
>  } odp_queue_capability_t;
>
>  /**
> @@ -124,6 +130,12 @@ typedef struct 

Re: [lng-odp] [PATCH v3] example: add IPv4 fragmentation/reassembly example

[Dmitry Eremin-Solenikov]

On 10.02.2017 19:06, Joe Savage wrote:
> Add an example application implementing lock-free IPv4 fragmentation
> and reassembly functionality using ODP's packet "concat" and "split".
> 
> Signed-off-by: Joe Savage 
> Reviewed-and-tested-by: Bill Fischofer 
> ---
> (This code contribution is provided under the terms of agreement 
> LES-LTM-21309)
> 

> diff --git a/example/ipfragreass/odp_ipfragreass_atomics.h 
> b/example/ipfragreass/odp_ipfragreass_atomics.h
> new file mode 100644
> index 000..bebe3d3
> --- /dev/null
> +++ b/example/ipfragreass/odp_ipfragreass_atomics.h
> @@ -0,0 +1,130 @@
> +/* Copyright (c) 2017, Linaro Limited
> + * All rights reserved.
> + *
> + * SPDX-License-Identifier: BSD-3-Clause
> + */
> +
> +#ifndef ODP_FRAGREASS_PP_ATOMICS_H_
> +#define ODP_FRAGREASS_PP_ATOMICS_H_
> +
> +#include 
> +
> +#if defined(__arm__) || defined(__aarch64__)
> +#if defined(__aarch64__)
> +static inline __int128 lld(__int128 *var, int mo);
> +static inline uint32_t scd(__int128 *var, __int128 neu, int mo);

Is there any reason to have prototypes, then main function, then lld/scd
implementation? What about moving lld/scd upwards, so that there would
be no extra prototypes?

> +static inline bool arm_atomic_strong_compare_exchange_16(__int128 *var,
> +  __int128 *exp,
> +  __int128 neu,
> +  int mo_success,
> +  int mo_failure
> +  EXAMPLE_UNUSED)
> +{
> + register __int128 old;
> + register __int128 expected = *exp;
> + int ll_mo, sc_mo;
> +
> + ll_mo = (mo_success != __ATOMIC_RELAXED &&
> +  mo_success != __ATOMIC_RELEASE) ? __ATOMIC_ACQUIRE
> +  : __ATOMIC_RELAXED;
> + sc_mo = (mo_success == __ATOMIC_RELEASE ||
> +  mo_success == __ATOMIC_ACQ_REL ||
> +  mo_success == __ATOMIC_SEQ_CST) ? __ATOMIC_RELEASE
> +  : __ATOMIC_RELAXED;
> +
> + /*
> +  * To prevent spurious failures and ensure atomicity, we must write some
> +  * value back -- whether it's the value we wanted to write, or the value
> +  * that is currently there. Repeat until we perform a successful write.
> +  */
> + do {
> + old = lld(var, ll_mo);
> + } while (scd(var, old == expected ? neu : old, sc_mo));
> +
> + *exp = old;
> + return (old == expected);
> +}
> +
> +static inline __int128 lld(__int128 *var, int mo)
> +{
> + __int128 old;
> +
> + if (mo == __ATOMIC_ACQUIRE)
> + __asm__ volatile("ldaxp %0, %H0, [%1]" : "=" (old)
> +  : "r" (var) : "memory");
> + else /* mo == __ATOMIC_RELAXED */
> + __asm__ volatile("ldxp %0, %H0, [%1]" : "=" (old)
> +  : "r" (var) : );
> + return old;
> +}
> +
> +static inline uint32_t scd(__int128 *var, __int128 neu, int mo)
> +{
> + uint32_t ret;
> +
> + if (mo == __ATOMIC_RELEASE)
> + __asm__ volatile("stlxp %w0, %1, %H1, [%2]" : "=" (ret)
> +  : "r" (neu), "r" (var) : "memory");
> + else /* mo == __ATOMIC_RELAXED */
> + __asm__ volatile("stxp %w0, %1, %H1, [%2]" : "=" (ret)
> +  : "r" (neu), "r" (var) : );
> + return ret;
> +}

-- 
With best wishes
Dmitry

Re: [lng-odp] [PATCH v3] example: add IPv4 fragmentation/reassembly example

[Dmitry Eremin-Solenikov]

On 12.04.2017 14:05, Joe Savage wrote:
> On 12/04/17 11:32, Maxim Uvarov wrote:
>> On 12.04.2017 13:15, Joe Savage wrote:
>> The problem is that when we discussed this patch on ODP call people very
>> worry about having 128bit instructions in ODP examples. At least Petri
>> and Barry asked if it would be possible to rewrite that with 64 bit
>> instructions? Some compilers might not support 128 bits and we need to
>> test it more.
>
> On 32-bit platforms, it already does use 64-bit atomics. In general, 
> though,
> the example hinges around having atomics that are twice the pointer size.
> We've actually discussed this on the list already in the thread "32-bit
> support in examples". Even if lock-free implementations can't be used,
> compilers can (and frequently do?) provide a lock-based compare exchange
> operation.

 Any progress on this?
>>>
>>> This is getting mildly ridiculous now — it's nearing three months since I
>>> initially submitted this simple example patch, and there's still no end in
>>> sight! Maxim: any status updates?
>>>
>>
>> Dmitry wanted to write some big review for that patch. But I do not see
>> anything here. People commented on 128 bit instructions in examples and
>> nobody set their review-by. I will rise question about your patch one
>> more time on arch call. I can not include things where we did not get
>> common agreement. I do not see anything bad with this patch but we need
>> account all existence odp platforms.

Forgot to mention. Your implementation seems build fine for MIPS64, so
there should be no more issues from my side.

-- 
With best wishes
Dmitry

Re: [lng-odp] [PATCH v3] example: add IPv4 fragmentation/reassembly example

[Dmitry Eremin-Solenikov]

On 12.04.2017 14:05, Joe Savage wrote:
> On 12/04/17 11:32, Maxim Uvarov wrote:
>> On 12.04.2017 13:15, Joe Savage wrote:
>> The problem is that when we discussed this patch on ODP call people very
>> worry about having 128bit instructions in ODP examples. At least Petri
>> and Barry asked if it would be possible to rewrite that with 64 bit
>> instructions? Some compilers might not support 128 bits and we need to
>> test it more.
>
> On 32-bit platforms, it already does use 64-bit atomics. In general, 
> though,
> the example hinges around having atomics that are twice the pointer size.
> We've actually discussed this on the list already in the thread "32-bit
> support in examples". Even if lock-free implementations can't be used,
> compilers can (and frequently do?) provide a lock-based compare exchange
> operation.

 Any progress on this?
>>>
>>> This is getting mildly ridiculous now — it's nearing three months since I
>>> initially submitted this simple example patch, and there's still no end in
>>> sight! Maxim: any status updates?
>>>
>>
>> Dmitry wanted to write some big review for that patch. But I do not see
>> anything here. People commented on 128 bit instructions in examples and
>> nobody set their review-by. I will rise question about your patch one
>> more time on arch call. I can not include things where we did not get
>> common agreement. I do not see anything bad with this patch but we need
>> account all existence odp platforms.

I'm sorry for the delay. Was quite under a pile of IPsec stuff...

I'm quite not happy about intermixture of arch-dependent and
arch-specific stuff in headers. Would it be possible to split
arch-specific implementation details to per-arch headers (one for
AArch64, one for older ARM and one generic) and include proper header
based on the $(ARCH_DIR)? It would be especially nice to have such
header provide ATOMIC_STRONG_CAS_DBLPTR (or maybe just
atomic_strong_cas_dblptr() ).

> 
> I totally appreciate that some form of agreement needs to be reached before a
> given patch can be merged, but I don't think that leaving me in the dark about
> the status of such issues is a particularly good way to run things. (This is
> hardly a healthy process for encouraging contributions.)
> 
> As I mentioned in the previous discussions (to no response), lock-based
> compare exchange implementations are perfectly acceptable, and thus there
> should not be any earth shattering compatibility issues here.
> 


-- 
With best wishes
Dmitry

Re: [lng-odp] [API-NEXT PATCH v2 0/4] Deprecated macros

[Bill Fischofer]

On Wed, Apr 12, 2017 at 7:11 AM, Dmitry Eremin-Solenikov
 wrote:
> On 12.04.2017 14:50, Savolainen, Petri (Nokia - FI/Espoo) wrote:
>>
>>
>>> -Original Message-
>>> From: Dmitry Eremin-Solenikov [mailto:dmitry.ereminsoleni...@linaro.org]
>>> Sent: Wednesday, April 12, 2017 2:32 PM
>>> To: Petri Savolainen ; lng-
>>> o...@lists.linaro.org
>>> Subject: Re: [lng-odp] [API-NEXT PATCH v2 0/4] Deprecated macros
>>>
>>> On 30.03.2017 16:58, Petri Savolainen wrote:
 Replaced ODP_DEPRECATED macro (which was based on GCC __attribute__)
>>> with
 compiler independent mechanism to control if deprecated API definitions
>>> are
 visible to the application. ODP_DEPRECATED_API can be used both in
>>> application
 and implementation to check if deprecated APIs are enabled. By default
>>> those are
 disabled. Implementation may optimize the normal (new API) code path.

 ODP_DEPRECATE() macro is used to rename definitions, so that data
>>> structure
 sizes are equal on both options. This enables implementation to serve
>>> both
 options with a single library (if it wishes to do so).
>>>
>>> My main question remains as it was before: is it possible for the
>>> distribution to supply (unoptimized) ODP binary and headers and then for
>>> the application to select if it builds with or without deprecated API
>>> using that binary/headers?
>>
>>
>> Yes. This patch set keeps the same struct fields/etc for both modes - only 
>> the names are scrambled (with __deprecated_ prefix) when deprecated APIs are 
>> not supported (the default).
>
> If so. Consider I have built and installed ODP headers & binary built
> with --enable-deprecated-api.
>
> How do I build:
>
> - application that uses deprecated API?
>   [I assume that the answer to this question is trivial: just build as is].
>
> - application that wants to be sure that it does not use deprecated API?

As a practical matter, the support of deprecated APIs is similar to
the current provision for debug builds (--enable-debug and
--enable-debug-print in the current ./configure script). These really
are only of significance in the embedded space. In the cloud profile,
applications use whatever ODP release(s) are installed on the system
and the normal library-matchings are used to ensure that applications
built for Release X are paired with library .so files compatible with
that release. In this case, there are no deprecated APIs since
applications only move to newer ODP release levels when they are
ready. A cloud host system may specify the minimum ODP release level
available on it, and that determines when laggards need to upgrade.

So ODP will never ship a distribution that was configured with
--enable-deprecated-api. The only users of this feature will be
embedded applications that are customizing ODP to their own needs.

>
>
> --
> With best wishes
> Dmitry

Re: [lng-odp] [API-NEXT PATCH v2 0/4] Deprecated macros

[Dmitry Eremin-Solenikov]

On 12.04.2017 14:50, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> 
> 
>> -Original Message-
>> From: Dmitry Eremin-Solenikov [mailto:dmitry.ereminsoleni...@linaro.org]
>> Sent: Wednesday, April 12, 2017 2:32 PM
>> To: Petri Savolainen ; lng-
>> o...@lists.linaro.org
>> Subject: Re: [lng-odp] [API-NEXT PATCH v2 0/4] Deprecated macros
>>
>> On 30.03.2017 16:58, Petri Savolainen wrote:
>>> Replaced ODP_DEPRECATED macro (which was based on GCC __attribute__)
>> with
>>> compiler independent mechanism to control if deprecated API definitions
>> are
>>> visible to the application. ODP_DEPRECATED_API can be used both in
>> application
>>> and implementation to check if deprecated APIs are enabled. By default
>> those are
>>> disabled. Implementation may optimize the normal (new API) code path.
>>>
>>> ODP_DEPRECATE() macro is used to rename definitions, so that data
>> structure
>>> sizes are equal on both options. This enables implementation to serve
>> both
>>> options with a single library (if it wishes to do so).
>>
>> My main question remains as it was before: is it possible for the
>> distribution to supply (unoptimized) ODP binary and headers and then for
>> the application to select if it builds with or without deprecated API
>> using that binary/headers?
> 
> 
> Yes. This patch set keeps the same struct fields/etc for both modes - only 
> the names are scrambled (with __deprecated_ prefix) when deprecated APIs are 
> not supported (the default).

If so. Consider I have built and installed ODP headers & binary built
with --enable-deprecated-api.

How do I build:

- application that uses deprecated API?
  [I assume that the answer to this question is trivial: just build as is].

- application that wants to be sure that it does not use deprecated API?


-- 
With best wishes
Dmitry

Re: [lng-odp] [API-NEXT PATCH v2 0/4] Deprecated macros

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

> -Original Message-
> From: Dmitry Eremin-Solenikov [mailto:dmitry.ereminsoleni...@linaro.org]
> Sent: Wednesday, April 12, 2017 2:32 PM
> To: Petri Savolainen ; lng-
> o...@lists.linaro.org
> Subject: Re: [lng-odp] [API-NEXT PATCH v2 0/4] Deprecated macros
> 
> On 30.03.2017 16:58, Petri Savolainen wrote:
> > Replaced ODP_DEPRECATED macro (which was based on GCC __attribute__)
> with
> > compiler independent mechanism to control if deprecated API definitions
> are
> > visible to the application. ODP_DEPRECATED_API can be used both in
> application
> > and implementation to check if deprecated APIs are enabled. By default
> those are
> > disabled. Implementation may optimize the normal (new API) code path.
> >
> > ODP_DEPRECATE() macro is used to rename definitions, so that data
> structure
> > sizes are equal on both options. This enables implementation to serve
> both
> > options with a single library (if it wishes to do so).
> 
> My main question remains as it was before: is it possible for the
> distribution to supply (unoptimized) ODP binary and headers and then for
> the application to select if it builds with or without deprecated API
> using that binary/headers?


Yes. This patch set keeps the same struct fields/etc for both modes - only the 
names are scrambled (with __deprecated_ prefix) when deprecated APIs are not 
supported (the default).

-Petri
 

> 
> Do we want to support such cases?
> 
> --
> With best wishes
> Dmitry

Re: [lng-odp] [API-NEXT PATCH v2 0/4] Deprecated macros

[Dmitry Eremin-Solenikov]

On 30.03.2017 16:58, Petri Savolainen wrote:
> Replaced ODP_DEPRECATED macro (which was based on GCC __attribute__) with 
> compiler independent mechanism to control if deprecated API definitions are 
> visible to the application. ODP_DEPRECATED_API can be used both in 
> application 
> and implementation to check if deprecated APIs are enabled. By default those 
> are
> disabled. Implementation may optimize the normal (new API) code path.
> 
> ODP_DEPRECATE() macro is used to rename definitions, so that data structure 
> sizes are equal on both options. This enables implementation to serve both 
> options with a single library (if it wishes to do so).

My main question remains as it was before: is it possible for the
distribution to supply (unoptimized) ODP binary and headers and then for
the application to select if it builds with or without deprecated API
using that binary/headers?

Do we want to support such cases?

-- 
With best wishes
Dmitry

Re: [lng-odp] [PATCH] api: ipsec: change semantics of odp_ipsec_result function

[Dmitry Eremin-Solenikov]

On 12.04.2017 12:44, Savolainen, Petri (Nokia - FI/Espoo) wrote:
> 
> 
>> -Original Message-
>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>> Dmitry Eremin-Solenikov
>> Sent: Tuesday, April 11, 2017 2:02 AM
>> To: lng-odp@lists.linaro.org
>> Subject: [lng-odp] [PATCH] api: ipsec: change semantics of
>> odp_ipsec_result function
>>
>>  - Move packets from the event instead of copying them. This simplifies
>>event handling/freeing code, which now does not have to track, which
>>packets were copied from the event and which packets should be freed.
> 
> Current spec is stateless. If array is too small in the first call, 
> application must call again with larger array. Application must not 
> proceeding to access packets, before large enough array is used and result 
> event is "freed". 

I think this can be troublesome for the application. Because if the
array is too small, it has to dynamically allocate new array (be it a
call to malloc, alloca or just dynamic on-stack arrays with variable
size). If API allows the application to do 'partial processing', there
would be no dynamic allocation inside the app at this point.

Are we OK with dynamic allocation at this point?

>>  - Do not require to free the event before processing packets. This
>>allows one to copy packets from the event in small batches and
>>process them accordingly.
> 
> This *disallows* implementation to use the packet as the results event.

I remember we talked about ipsec-result-event-as-packet on the previous
arch call. I gave it a though. IIRC, your idea was that odp_event_free
in this case can just change the type of the event (from IPSEC_RESULT to
PACKET). And I had some troubles with this idea. Because now
odp_event_free() combines two different code paths for IPSEC_RESULT:

- If the event was successfully passed through odp_ipsec_result(),
just change the event type.

- If it did not pass through odp_ipsec_result() or if the call did not
succeed, actually free the event/packet.

This introduces extra state into the IPSEC_RESULT context data.

> Current spec allows implementation (e.g HW) to enqueue a packet with an IPSEC 
> flag set, and use that as the result event. The conversion function + free 
> can modify the event type from IPSEC result to packet. This is how crypto 
> works today, although the spec is not explicit enough about it.

I see your point, I dislike this 'don't actually free' behaviour of
odp_event_free() if the odp_ipsec_result() was successful.

What if we change the requirements in the following way:

If the event was fully processed by odp_ipsec_result(), application may
not call odp_event_free() on it. Successful odp_ipsec_result() consumes
and frees the event on its own.

What do you think?


-- 
With best wishes
Dmitry

Re: [lng-odp] [PATCH v3] example: add IPv4 fragmentation/reassembly example

[Bill Fischofer]

I've added this to today's ARCH call agenda.

On Wed, Apr 12, 2017 at 5:32 AM, Maxim Uvarov  wrote:
> On 12.04.2017 13:15, Joe Savage wrote:
> The problem is that when we discussed this patch on ODP call people very
> worry about having 128bit instructions in ODP examples. At least Petri
> and Barry asked if it would be possible to rewrite that with 64 bit
> instructions? Some compilers might not support 128 bits and we need to
> test it more.

 On 32-bit platforms, it already does use 64-bit atomics. In general, 
 though,
 the example hinges around having atomics that are twice the pointer size.
 We've actually discussed this on the list already in the thread "32-bit
 support in examples". Even if lock-free implementations can't be used,
 compilers can (and frequently do?) provide a lock-based compare exchange
 operation.
>>>
>>> Any progress on this?
>>
>> This is getting mildly ridiculous now — it's nearing three months since I
>> initially submitted this simple example patch, and there's still no end in
>> sight! Maxim: any status updates?
>>
>
> Dmitry wanted to write some big review for that patch. But I do not see
> anything here. People commented on 128 bit instructions in examples and
> nobody set their review-by. I will rise question about your patch one
> more time on arch call. I can not include things where we did not get
> common agreement. I do not see anything bad with this patch but we need
> account all existence odp platforms.
>
> Maxim.

Re: [lng-odp] [PATCH v3] example: add IPv4 fragmentation/reassembly example

[Joe Savage]

On 12/04/17 11:32, Maxim Uvarov wrote:
> On 12.04.2017 13:15, Joe Savage wrote:
>  The problem is that when we discussed this patch on ODP call people very
>  worry about having 128bit instructions in ODP examples. At least Petri
>  and Barry asked if it would be possible to rewrite that with 64 bit
>  instructions? Some compilers might not support 128 bits and we need to
>  test it more.
> >>>
> >>> On 32-bit platforms, it already does use 64-bit atomics. In general, 
> >>> though,
> >>> the example hinges around having atomics that are twice the pointer size.
> >>> We've actually discussed this on the list already in the thread "32-bit
> >>> support in examples". Even if lock-free implementations can't be used,
> >>> compilers can (and frequently do?) provide a lock-based compare exchange
> >>> operation.
> >>
> >> Any progress on this?
> > 
> > This is getting mildly ridiculous now — it's nearing three months since I
> > initially submitted this simple example patch, and there's still no end in
> > sight! Maxim: any status updates?
> > 
> 
> Dmitry wanted to write some big review for that patch. But I do not see
> anything here. People commented on 128 bit instructions in examples and
> nobody set their review-by. I will rise question about your patch one
> more time on arch call. I can not include things where we did not get
> common agreement. I do not see anything bad with this patch but we need
> account all existence odp platforms.

I totally appreciate that some form of agreement needs to be reached before a
given patch can be merged, but I don't think that leaving me in the dark about
the status of such issues is a particularly good way to run things. (This is
hardly a healthy process for encouraging contributions.)

As I mentioned in the previous discussions (to no response), lock-based
compare exchange implementations are perfectly acceptable, and thus there
should not be any earth shattering compatibility issues here.

Re: [lng-odp] [PATCH v3] example: add IPv4 fragmentation/reassembly example

[Maxim Uvarov]

On 12.04.2017 13:15, Joe Savage wrote:
 The problem is that when we discussed this patch on ODP call people very
 worry about having 128bit instructions in ODP examples. At least Petri
 and Barry asked if it would be possible to rewrite that with 64 bit
 instructions? Some compilers might not support 128 bits and we need to
 test it more.
>>>
>>> On 32-bit platforms, it already does use 64-bit atomics. In general, though,
>>> the example hinges around having atomics that are twice the pointer size.
>>> We've actually discussed this on the list already in the thread "32-bit
>>> support in examples". Even if lock-free implementations can't be used,
>>> compilers can (and frequently do?) provide a lock-based compare exchange
>>> operation.
>>
>> Any progress on this?
> 
> This is getting mildly ridiculous now — it's nearing three months since I
> initially submitted this simple example patch, and there's still no end in
> sight! Maxim: any status updates?
> 

Dmitry wanted to write some big review for that patch. But I do not see
anything here. People commented on 128 bit instructions in examples and
nobody set their review-by. I will rise question about your patch one
more time on arch call. I can not include things where we did not get
common agreement. I do not see anything bad with this patch but we need
account all existence odp platforms.

Maxim.

Re: [lng-odp] [PATCH v3] example: add IPv4 fragmentation/reassembly example

[Joe Savage]

> > > The problem is that when we discussed this patch on ODP call people very
> > > worry about having 128bit instructions in ODP examples. At least Petri
> > > and Barry asked if it would be possible to rewrite that with 64 bit
> > > instructions? Some compilers might not support 128 bits and we need to
> > > test it more.
> > 
> > On 32-bit platforms, it already does use 64-bit atomics. In general, though,
> > the example hinges around having atomics that are twice the pointer size.
> > We've actually discussed this on the list already in the thread "32-bit
> > support in examples". Even if lock-free implementations can't be used,
> > compilers can (and frequently do?) provide a lock-based compare exchange
> > operation.
> 
> Any progress on this?

This is getting mildly ridiculous now — it's nearing three months since I
initially submitted this simple example patch, and there's still no end in
sight! Maxim: any status updates?

Re: [lng-odp] [API-NEXT PATCH v2 08/16] test: scheduler: Fixup calling release operations

[Maxim Uvarov]

Brian, can you please resend all patches as new version of patch set.
Not embed them into current email thread. I think it will be more easy
for second review.

Maxim.

On 04.04.2017 21:48, Brian Brooks wrote:
> Remove erroneous assertion that is handled in later code
> 
> Signed-off-by: Kevin Wang 
> Reviewed-by: Ola Liljedahl 
> ---
>  test/common_plat/validation/api/scheduler/scheduler.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/test/common_plat/validation/api/scheduler/scheduler.c 
> b/test/common_plat/validation/api/scheduler/scheduler.c
> index 952561cd..bc486192 100644
> --- a/test/common_plat/validation/api/scheduler/scheduler.c
> +++ b/test/common_plat/validation/api/scheduler/scheduler.c
> @@ -251,7 +251,10 @@ void scheduler_test_queue_destroy(void)
>   CU_ASSERT_FATAL(u32[0] == MAGIC);
>  
>   odp_buffer_free(buf);
> - odp_schedule_release_ordered();
> + if (qp.sched.sync == ODP_SCHED_SYNC_ATOMIC)
> + odp_schedule_release_atomic();
> + else if (qp.sched.sync == ODP_SCHED_SYNC_ORDERED)
> + odp_schedule_release_ordered();
>  
>   CU_ASSERT_FATAL(odp_queue_destroy(queue) == 0);
>   }
> @@ -478,6 +481,11 @@ void scheduler_test_groups(void)
>   odp_schedule_group_leave(mygrp1, );
>   odp_schedule_group_leave(mygrp2, );
>  
> + if (qp.sched.sync == ODP_SCHED_SYNC_ATOMIC)
> + odp_schedule_release_atomic();
> + else if (qp.sched.sync == ODP_SCHED_SYNC_ORDERED)
> + odp_schedule_release_ordered();
> +
>   /* Done with queues for this round */
>   CU_ASSERT_FATAL(odp_queue_destroy(queue_grp1) == 0);
>   CU_ASSERT_FATAL(odp_queue_destroy(queue_grp2) == 0);
> @@ -959,7 +967,6 @@ static void fill_queues(thread_args_t *args)
>   }
>  
>   ret = odp_queue_enq(queue, ev);
> - CU_ASSERT_FATAL(ret == 0);
>  
>   if (ret)
>   odp_buffer_free(buf);
> 

Re: [lng-odp] [PATCH 3/3] linux-gen: sched: optimize group scheduling

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

Ping.

This patch set removes the non-deterministic latency, lower QoS and potential 
queue starvation that is caused by this code ...

-   if (grp > ODP_SCHED_GROUP_ALL &&
-   !odp_thrmask_isset(>sched_grp[grp].mask,
-  sched_local.thr)) {
-   /* This thread is not eligible for work from
-* this queue, so continue scheduling it.
-*/
-   ring_enq(ring, PRIO_QUEUE_MASK, qi);
-
-   i++;
-   id++;
-   continue;
-   }


... which sends queues of "wrong" group back to the end of the priority queue. 
If e.g. tens of threads are sending it back and only one thread would accept 
it, it's actually very likely that queue service level is much lower than it 
should be.

Improved latency can be seen already with the new l2fwd -g option. 

-Petri


> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Petri
> Savolainen
> Sent: Thursday, April 06, 2017 2:59 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCH 3/3] linux-gen: sched: optimize group scheduling
> 
> Use separate priority queues for different groups. Sharing
> the same priority queue over multiple groups caused multiple
> issues:
> * latency and ordering issues when threads push back
>   events (from wrong groups) to the tail of the priority queue
> * unnecessary contention (scaling issues) when threads belong
>   to different groups
> 
> Lowered the maximum number of groups from 256 to 32 (in the default
> configuration) to limit memory usage of priority queues. This should
> be enough for the most users.
> 
> Signed-off-by: Petri Savolainen 
> ---
>  platform/linux-generic/odp_schedule.c | 284 +++--
> -
>  1 file changed, 195 insertions(+), 89 deletions(-)
> 
> diff --git a/platform/linux-generic/odp_schedule.c b/platform/linux-
> generic/odp_schedule.c
> index e7079b9..f366e7e 100644
> --- a/platform/linux-generic/odp_schedule.c
> +++ b/platform/linux-generic/odp_schedule.c
> @@ -34,7 +34,7 @@ ODP_STATIC_ASSERT((ODP_SCHED_PRIO_NORMAL > 0) &&
> "normal_prio_is_not_between_highest_and_lowest");
> 
>  /* Number of scheduling groups */
> -#define NUM_SCHED_GRPS 256
> +#define NUM_SCHED_GRPS 32
> 
>  /* Priority queues per priority */
>  #define QUEUES_PER_PRIO  4
> @@ -163,7 +163,11 @@ typedef struct {
>   ordered_stash_t stash[MAX_ORDERED_STASH];
>   } ordered;
> 
> + uint32_t grp_epoch;
> + int num_grp;
> + uint8_t grp[NUM_SCHED_GRPS];
>   uint8_t weight_tbl[WEIGHT_TBL_SIZE];
> + uint8_t grp_weight[WEIGHT_TBL_SIZE];
> 
>  } sched_local_t;
> 
> @@ -199,7 +203,7 @@ typedef struct {
>   pri_mask_t pri_mask[NUM_PRIO];
>   odp_spinlock_t mask_lock;
> 
> - prio_queue_t   prio_q[NUM_PRIO][QUEUES_PER_PRIO];
> + prio_queue_t
> prio_q[NUM_SCHED_GRPS][NUM_PRIO][QUEUES_PER_PRIO];
> 
>   odp_spinlock_t poll_cmd_lock;
>   /* Number of commands in a command queue */
> @@ -214,8 +218,10 @@ typedef struct {
>   odp_shm_t  shm;
>   uint32_t   pri_count[NUM_PRIO][QUEUES_PER_PRIO];
> 
> - odp_spinlock_t grp_lock;
> - odp_thrmask_t mask_all;
> + odp_thrmask_tmask_all;
> + odp_spinlock_t   grp_lock;
> + odp_atomic_u32_t grp_epoch;
> +
>   struct {
>   char   name[ODP_SCHED_GROUP_NAME_LEN];
>   odp_thrmask_t  mask;
> @@ -223,6 +229,7 @@ typedef struct {
>   } sched_grp[NUM_SCHED_GRPS];
> 
>   struct {
> + int grp;
>   int prio;
>   int queue_per_prio;
>   } queue[ODP_CONFIG_QUEUES];
> @@ -273,7 +280,7 @@ static void sched_local_init(void)
>  static int schedule_init_global(void)
>  {
>   odp_shm_t shm;
> - int i, j;
> + int i, j, grp;
> 
>   ODP_DBG("Schedule init ... ");
> 
> @@ -293,15 +300,20 @@ static int schedule_init_global(void)
>   sched->shm  = shm;
>   odp_spinlock_init(>mask_lock);
> 
> - for (i = 0; i < NUM_PRIO; i++) {
> - for (j = 0; j < QUEUES_PER_PRIO; j++) {
> - int k;
> + for (grp = 0; grp < NUM_SCHED_GRPS; grp++) {
> + for (i = 0; i < NUM_PRIO; i++) {
> + for (j = 0; j < QUEUES_PER_PRIO; j++) {
> + prio_queue_t *prio_q;
> + int k;
> 
> - ring_init(>prio_q[i][j].ring);
> + prio_q = 
> >prio_q[grp][i][j];
> + ring_init(_q->ring);
> 
> - for (k = 0; k < PRIO_QUEUE_RING_SIZE; k++)
> - sched-
> >prio_q[i][j].queue_index[k] =
> -   

Re: [lng-odp] [API-NEXT PATCH v2 0/4] Deprecated macros

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

Ping.

> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Petri
> Savolainen
> Sent: Thursday, March 30, 2017 4:59 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [API-NEXT PATCH v2 0/4] Deprecated macros
> 
> Replaced ODP_DEPRECATED macro (which was based on GCC __attribute__) with
> compiler independent mechanism to control if deprecated API definitions
> are
> visible to the application. ODP_DEPRECATED_API can be used both in
> application
> and implementation to check if deprecated APIs are enabled. By default
> those are
> disabled. Implementation may optimize the normal (new API) code path.
> 
> ODP_DEPRECATE() macro is used to rename definitions, so that data
> structure
> sizes are equal on both options. This enables implementation to serve both
> options with a single library (if it wishes to do so).
> 
> 
> Petri Savolainen (4):
>   api: hints: remove ODP_DEPRECATED from API
>   api: deprecated: add configure option and macros
>   test: crypto: remove references to deprecated crypto apis
>   api: crypto: enforce deprecated API status
> 
>  configure.ac   | 19 +++-
>  doc/application-api-guide/api_guide_lines.dox  |  6 +--
>  doc/platform-api-guide/Doxyfile|  1 +
>  doc/process-guide/release-guide.adoc   |  6 +--
>  example/ipsec/odp_ipsec_misc.h |  4 +-
>  example/ipsec/odp_ipsec_sa_db.c|  4 +-
>  example/ipsec/odp_ipsec_stream.c   |  6 +--
>  include/odp/api/spec/.gitignore|  1 +
>  include/odp/api/spec/crypto.h  | 29 +++--
>  include/odp/api/spec/deprecated.h.in   | 50
> ++
>  include/odp/api/spec/hints.h   |  6 ---
>  include/odp_api.h  |  1 +
>  platform/Makefile.inc  |  1 +
>  platform/linux-generic/Makefile.am |  1 +
>  .../linux-generic/include/odp/api/deprecated.h | 26 +++
>  platform/linux-generic/odp_crypto.c| 45 +
> --
>  test/common_plat/performance/odp_crypto.c  |  4 +-
>  17 files changed, 161 insertions(+), 49 deletions(-)
>  create mode 100644 include/odp/api/spec/deprecated.h.in
>  create mode 100644 platform/linux-generic/include/odp/api/deprecated.h
> 
> --
> 2.8.1

Re: [lng-odp] [PATCH] api: ipsec: change semantics of odp_ipsec_result function

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

> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> Dmitry Eremin-Solenikov
> Sent: Tuesday, April 11, 2017 2:02 AM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCH] api: ipsec: change semantics of
> odp_ipsec_result function
> 
>  - Move packets from the event instead of copying them. This simplifies
>event handling/freeing code, which now does not have to track, which
>packets were copied from the event and which packets should be freed.

Current spec is stateless. If array is too small in the first call, application 
must call again with larger array. Application must not proceeding to access 
packets, before large enough array is used and result event is "freed". 

> 
>  - Do not require to free the event before processing packets. This
>allows one to copy packets from the event in small batches and
>process them accordingly.

This *disallows* implementation to use the packet as the results event.

Current spec allows implementation (e.g HW) to enqueue a packet with an IPSEC 
flag set, and use that as the result event. The conversion function + free can 
modify the event type from IPSEC result to packet. This is how crypto works 
today, although the spec is not explicit enough about it.


-Petri


> 
> Signed-off-by: Dmitry Eremin-Solenikov 
> ---
>  include/odp/api/spec/ipsec.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h
> index a0ceb11a..8c7750f7 100644
> --- a/include/odp/api/spec/ipsec.h
> +++ b/include/odp/api/spec/ipsec.h
> @@ -1278,8 +1278,7 @@ int odp_ipsec_out_inline(const odp_ipsec_op_param_t
> *op_param,
>   * Get IPSEC results from an ODP_EVENT_IPSEC_RESULT event
>   *
>   * Copies IPSEC operation results from an event. The event must be of
> - * type ODP_EVENT_IPSEC_RESULT. It must be freed before the application
> passes
> - * any resulting packet handles to other ODP calls.
> + * type ODP_EVENT_IPSEC_RESULT. It must be freed via odp_event_free().
>   *
>   * @param[out]result  Pointer to operation result for output. Maybe
> NULL, if
>   *application is interested only on the number of
> @@ -1288,7 +1287,8 @@ int odp_ipsec_out_inline(const odp_ipsec_op_param_t
> *op_param,
>   *
>   * @return Number of packets in the event. If this is larger than
>   * 'result.num_pkt', all packets did not fit into result struct
> and
> - * application must call the function again with a larger result
> struct.
> + * application must call the function again. Packets returned
> during
> + * previous calls will not be returned again in subsequent calls.
>   * @retval <0 On failure
>   *
>   * @see odp_ipsec_in_enq(), odp_ipsec_out_enq()
> --
> 2.11.0

Re: [lng-odp] [API-NEXT PATCH] validation: pktio: remove CRCs from parser test packets

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

Maxim,

Parser test revert was unnecessary, since this patch fixes the problem with tap 
interfaces! Please put the test back and merge this patch instead.

-Petri


> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> Savolainen, Petri (Nokia - FI/Espoo)
> Sent: Friday, April 07, 2017 2:37 PM
> To: Maxim Uvarov 
> Cc: lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [API-NEXT PATCH] validation: pktio: remove CRCs
> from parser test packets
> 
> Reviewed-and-tested-by: Petri Savolainen 
> 
> Currently make check (api-next) fails on the parser test (tap pktio) in my
> system. This patch corrects that. Please merge soon.
> 
> -Petri
> 
> 
> > -Original Message-
> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> > Matias Elo
> > Sent: Thursday, April 06, 2017 5:41 PM
> > To: lng-odp@lists.linaro.org
> > Subject: Suspected SPAM - [lng-odp] [API-NEXT PATCH] validation: pktio:
> > remove CRCs from parser test packets
> >
> > Remove precalculated CRCs from test packets. Some pktio devices may drop
> > CRCs causing the tests to fail.
> >
> > Signed-off-by: Matias Elo 
> > ---
> >  test/common_plat/validation/api/pktio/parser.h | 24 ---
> --
> > ---
> >  1 file changed, 12 insertions(+), 12 deletions(-)
> >
> > diff --git a/test/common_plat/validation/api/pktio/parser.h
> > b/test/common_plat/validation/api/pktio/parser.h
> > index 57c6238..5cc2b98 100644
> > --- a/test/common_plat/validation/api/pktio/parser.h
> > +++ b/test/common_plat/validation/api/pktio/parser.h
> > @@ -28,6 +28,8 @@ int parser_suite_init(void);
> >  /* test arrays: */
> >  extern odp_testinfo_t parser_suite[];
> >
> > +/* Test packets without CRC */
> > +
> >  /**
> >   * ARP request
> >   */
> > @@ -39,7 +41,7 @@ static const uint8_t test_packet_arp[] = {
> > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC0, 0xA8,
> > 0x01, 0x02, 0x00, 0x01, 0x02, 0x03, 0x04, 0x05,
> > 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D,
> > -   0x0E, 0x0F, 0x10, 0x11, 0xA1, 0xA8, 0x27, 0x43,
> > +   0x0E, 0x0F, 0x10, 0x11
> >  };
> >
> >  /**
> > @@ -53,7 +55,7 @@ static const uint8_t test_packet_ipv4_icmp[] = {
> > 0x01, 0x02, 0x00, 0x00, 0xB7, 0xAB, 0x00, 0x01,
> > 0x00, 0x02, 0x00, 0x01, 0x02, 0x03, 0x04, 0x05,
> > 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D,
> > -   0x0E, 0x0F, 0x10, 0x11, 0xD9, 0x7F, 0xE8, 0x02,
> > +   0x0E, 0x0F, 0x10, 0x11
> >  };
> >
> >  /**
> > @@ -67,7 +69,7 @@ static const uint8_t test_packet_ipv4_tcp[] = {
> > 0x01, 0x01, 0x04, 0xD2, 0x10, 0xE1, 0x00, 0x00,
> > 0x00, 0x01, 0x00, 0x00, 0x00, 0x02, 0x50, 0x00,
> > 0x00, 0x00, 0x0C, 0xCC, 0x00, 0x00, 0x00, 0x01,
> > -   0x02, 0x03, 0x04, 0x05, 0x2E, 0xDE, 0x5E, 0x48,
> > +   0x02, 0x03, 0x04, 0x05
> >  };
> >
> >  /**
> > @@ -81,7 +83,7 @@ static const uint8_t test_packet_ipv4_udp[] = {
> > 0x01, 0x01, 0x00, 0x3F, 0x00, 0x3F, 0x00, 0x1A,
> > 0x2F, 0x97, 0x00, 0x01, 0x02, 0x03, 0x04, 0x05,
> > 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D,
> > -   0x0E, 0x0F, 0x10, 0x11, 0x64, 0xF4, 0xE4, 0xB6,
> > +   0x0E, 0x0F, 0x10, 0x11
> >  };
> >
> >  /**
> > @@ -96,7 +98,7 @@ static const uint8_t test_packet_vlan_ipv4_udp[] = {
> > 0x01, 0x02, 0xC4, 0xA8, 0x01, 0x01, 0x00, 0x3F,
> > 0x00, 0x3F, 0x00, 0x16, 0x4D, 0xBF, 0x00, 0x01,
> > 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09,
> > -   0x0A, 0x0B, 0x0C, 0x0D, 0xCB, 0xBF, 0xD0, 0x29,
> > +   0x0A, 0x0B, 0x0C, 0x0D
> >  };
> >
> >  /**
> > @@ -112,7 +114,7 @@ static const uint8_t
> test_packet_vlan_qinq_ipv4_udp[]
> > = {
> > 0xF3, 0x73, 0xC0, 0xA8, 0x01, 0x02, 0xC4, 0xA8,
> > 0x01, 0x01, 0x00, 0x3F, 0x00, 0x3F, 0x00, 0x12,
> > 0x63, 0xDF, 0x00, 0x01, 0x02, 0x03, 0x04, 0x05,
> > -   0x06, 0x07, 0x08, 0x09, 0x80, 0x98, 0xB8, 0x18,
> > +   0x06, 0x07, 0x08, 0x09
> >  };
> >
> >  /**
> > @@ -126,8 +128,7 @@ static const uint8_t test_packet_ipv6_icmp[] = {
> > 0x09, 0xFF, 0xFE, 0x00, 0x04, 0x00, 0x35, 0x55,
> > 0x55, 0x55, 0x66, 0x66, 0x66, 0x66, 0x77, 0x77,
> > 0x77, 0x77, 0x88, 0x88, 0x88, 0x88, 0x80, 0x00,
> > -   0x1B, 0xC2, 0x00, 0x01, 0x00, 0x02, 0xE0, 0x68,
> > -   0x0E, 0xBA,
> > +   0x1B, 0xC2, 0x00, 0x01, 0x00, 0x02
> >  };
> >
> >  /**
> > @@ -143,7 +144,7 @@ static const uint8_t test_packet_ipv6_tcp[] = {
> > 0x77, 0x77, 0x88, 0x88, 0x88, 0x88, 0x04, 0xD2,
> > 0x10, 0xE1, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00,
> > 0x00, 0x02, 0x50, 0x00, 0x00, 0x00, 0x36, 0x37,
> > -   0x00, 0x00, 0x28, 0x67, 0xD2, 0xAF,
> > +   0x00, 0x00
> >  };
> >
> >  /**
> > @@ -157,8 +158,7 @@ static const uint8_t test_packet_ipv6_udp[] = {
> > 0x09, 0xFF, 0xFE, 0x00, 0x04, 0x00, 0x35, 0x55,
> > 0x55, 0x55, 0x66, 0x66, 0x66, 0x66, 0x77, 0x77,
> > 0x77, 0x77, 0x88, 0x88, 0x88, 0x88, 0x00, 0x3F,
> > -   0x00, 0x3F, 0x00, 0x08, 0x9B, 0x68, 0x35, 0xD3,
> > -   0x64, 0x49,
> > +   0x00, 0x3F, 

Re: [lng-odp] [API-NEXT PATCHv2 00/23] driver items registration and probing

[Yi He]

Hi, Bala, Shally and Mahipal

yes, I'll send the invitation booking François' 10:00AM, India/shanghai
afternoon time, can update the invitation if you have any suggestion.

Best Regards, Yi

On 12 April 2017 at 13:38, Bala Manoharan  wrote:

> Hi Yi,
>
> I am also interested in the meeting. Do send me an invite also.
>
> Regards,
> Bala
>
>
> On 12 April 2017 at 10:46, Challa, Mahipal 
> wrote:
> > Hi Yi,
> >
> >>This Thursday François would like to have a call (1:30 hours) to
> introduce knowledge, background and discussions he have had with
> >Christophe around DDF, all are welcome if you feel interested in DDF
> topics and please reply before Wednesday earlier afternoon and I'll >send
> meeting invitation to you.
> >
> >
> > I would like to participate in this meeting and am from India. Please
> see if it is feasible to schedule this meeting to accommodate us.
> >
> >
> > Regards,
> >
> > Mahipal
> >
> >
> > 
> > From: Verma, Shally
> > Sent: Wednesday, April 12, 2017 10:38 AM
> > To: Yi He; lng-odp
> > Cc: Narayana, Prasad Athreya; Challa, Mahipal
> > Subject: RE: [lng-odp] [API-NEXT PATCHv2 00/23] driver items
> registration and probing
> >
> >
> >
> > -Original Message-
> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Yi
> He
> > Sent: 11 April 2017 19:36
> > To: lng-odp 
> > Subject: Re: [lng-odp] [API-NEXT PATCHv2 00/23] driver items
> registration and probing
> >
> > Hi, team
> >
> > Today in odp cloud meeting we talked about the DDF status, before the
> new LNG colleague joining to take over the DDF works, I'll take the
> ownership of the DDF and continue to move this patch series forward and
> related bugs, comments.
> >
> > This Thursday François would like to have a call (1:30 hours) to
> introduce knowledge, background and discussions he have had with Christophe
> around DDF, all are welcome if you feel interested in DDF topics and please
> reply before Wednesday earlier afternoon and I'll send meeting invitation
> to you.
> >
> > I would be interested to join same. However I am based out of India. So
> please see if it would be feasible to schedule meeting to accommodate India
> time zone.
> > Thanks
> > Shally
> >
> > thanks and best regards, Yi
> >
> > On 22 March 2017 at 22:48, Christophe Milard <
> christophe.mil...@linaro.org>
> > wrote:
> >
> >> This patch series can be pulled from:
> >> https://git.linaro.org/people/christophe.milard/odp.git/log/
> >> ?h=drv_framework_v2
> >>
> >> Since V1: Fixes following Bill's comments.
> >>
> >> Note: I am not really sure this is still in phase with what was
> >> discussed at connect, since I couldn't attend. But, at least I did the
> >> changes following the comments I recieved. Hope that still makes
> >> sence.
> >> Also, I am aware that patch 1 generates a warning: I copied this part
> >> from the north API so I assume this is an agreed decision.
> >>
> >> This patch series implements the driver interface, i.e.
> >> enumerator class, enumerator, devio and drivers registration and
> probing.
> >> This interface is depicted in:
> >> https://docs.google.com/document/d/1eCKPJF6uSlOllXi_
> >> sKDvRwUD2BXm-ZzxZoKT0nVEsl4/edit
> >> The associated tests are testing these mechanisms. Note that these
> >> tests are testing staticaly linked modules only (hence avoiding the
> >> module/platform/test debate). Also note that these tests are gathering
> >> all the elements (enumerators, enumerator classes, devio, drivers)
> >> making up the driver interface so as their interactions can be checked.
> >> Real elements (pci enumerators, drivers...) will likely be written in
> >> a much more stand-alone way.
> >>
> >> Christophe Milard (23):
> >>   drv: adding compiler hints in the driver interface
> >>   linux-gen: adding compiler hints in the driver interface
> >>   drv: making parameter strings dynamically computable
> >>   linux-gen: drv: enumerator_class registration
> >>   test: drv: enumerator_class registration tests
> >>   linux-gen: drv: enumerator registration
> >>   test: drv: enumerator registration tests
> >>   drv: driver: change drv unbind function name and pass correct
> >> parameter
> >>   drv: driver: add callback function for device destruction
> >>   linux-gen: drv: device creation and deletion
> >>   drv: driver: adding device query function
> >>   linux-gen: drv: driver: adding device querry function
> >>   test: drv: device creation and destruction
> >>   drv: driver: adding a probe and remove callback for devio
> >>   linux-gen: drv: devio registration
> >>   test: drv: devio creation and destruction
> >>   drv: adding driver remove function
> >>   drv: complement parameters to the driver probe() function
> >>   linux-gen: driver registration and probing
> >>   test: drv: driver registration and probing
> >>   drv: driver: adding functions to attach driver's data to the device
> >>