[lng-odp] api-next broken?

[shally verma]

I was trying api-next from linaro/odp as of today and am seeing this
error. Am I missing anything here?

I simply use
./bootstrap
./configure
./make

make[2]: Entering directory
`/home/shrutika/zip/zip-linux/83xx/odp/odp/example/ipfragreass'
  CC   odp_ipfragreass-odp_ipfragreass.o
  CC   odp_ipfragreass-odp_ipfragreass_fragment.o
  CC   odp_ipfragreass-odp_ipfragreass_helpers.o
  CC   odp_ipfragreass-odp_ipfragreass_reassemble.o
  CCLD odp_ipfragreass
odp_ipfragreass-odp_ipfragreass_reassemble.o: In function
`atomic_strong_cas_dblptr':
/home/shrutika/zip/zip-linux/83xx/odp/odp/example/ipfragreass/odp_ipfragreass_atomics.h:51:
undefined reference to `__atomic_compare_exchange_16'
/home/shrutika/zip/zip-linux/83xx/odp/odp/example/ipfragreass/odp_ipfragreass_atomics.h:51:
undefined reference to `__atomic_compare_exchange_16'
/home/shrutika/zip/zip-linux/83xx/odp/odp/example/ipfragreass/odp_ipfragreass_atomics.h:51:
undefined reference to `__atomic_compare_exchange_16'
collect2: error: ld returned 1 exit status
make[2]: *** [odp_ipfragreass] Error 1

Thanks
Shally

Re: [lng-odp] [PATCH API-NEXT v8 1/1] comp: compression spec

[shally verma]

On Tue, Aug 29, 2017 at 10:41 PM, Dmitry Eremin-Solenikov
<dmitry.ereminsoleni...@linaro.org> wrote:
> On 29/08/17 19:18, shally verma wrote:
>> Alongside a question of retrieving results for synchronous operations,
>> have one more questions - in crypto, I dont see separate output packet
>> data range. So, does it mean it writes to same offset and uses same
>> length as mentioned for input packet?
>
> Yes. Aside of padding, encryption does not change data length (and we do
> not support padding ATM). Hash is written at hash_result_offset offset.
>
> --
Ok. and could you also clarify on this
" retrieving results for synchronous call odp_crypto_op(const pkt_in[]
...)" . How do user get result per packet after this call is over ?

Thanks
Shally

> With best wishes
> Dmitry

Re: [lng-odp] [PATCH API-NEXT v8 1/1] comp: compression spec

[shally verma]

On Tue, Aug 29, 2017 at 6:06 PM, shally verma
<shallyvermacav...@gmail.com> wrote:
> On Tue, Aug 29, 2017 at 5:02 PM, Savolainen, Petri (Nokia - FI/Espoo)
> <petri.savolai...@nokia.com> wrote:
>>
>>
>>> -Original Message-
>>> From: shally verma [mailto:shallyvermacav...@gmail.com]
>>> Sent: Tuesday, August 29, 2017 10:26 AM
>>> To: Narayana Prasad Athreya <pathr...@caviumnetworks.com>
>>> Cc: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia.com>;
>>> Github ODP bot <odp...@yandex.ru>; lng-odp@lists.linaro.org; Narayana,
>>> Prasad Athreya <prasadathreya.naray...@cavium.com>; Mahipal Challa
>>> <mcha...@cavium.com>; Verma, Shally <shally.ve...@cavium.com>
>>> Subject: Re: [lng-odp] [PATCH API-NEXT v8 1/1] comp: compression spec
>>>
>>> Based on last discussion, I was reworking to add odp_comp_op_pkt ()
>>> API based on Crypto design. Help me to answer with these questions:
>>>
>>> 1. Current crypto packet base API is not giving Error code as an
>>> output to its sync version i.e. in int odp_crypto_op(const
>>> odp_packet_t pkt_in[],..), I do not see where it is returning
>>> odp_crypto_packet_result_t. Can anyone help?
>>
>> Error codes are part of operation results:
>>
>> /**
>>  * Get crypto operation results from an crypto processed packet
>>  *
>>  * Successful crypto operations of all types (SYNC and ASYNC) produce packets
>>  * which contain crypto result metadata. This function copies the operation
>>  * results from an crypto processed packet. Event subtype of this kind of
>>  * packet is ODP_EVENT_PACKET_crypto. Results are undefined if a non-crypto
>>  * processed packet is passed as input.
>>  *
>>  * @param packet  An crypto processed packet 
>> (ODP_EVENT_PACKET_CRYPTO)
>>  * @param[out]result  Pointer to operation result for output
>>  *
>>  * @retval  0 On success
>>  * @retval <0 On failure
>>  */
>> int odp_crypto_result(odp_crypto_packet_result_t *result,
>>   odp_packet_t packet);
>
> Ok. That seems user need to make explicit call to this API to get
> result, if he want.
> So this is optional call in crypto context?
>
Alongside a question of retrieving results for synchronous operations,
have one more questions - in crypto, I dont see separate output packet
data range. So, does it mean it writes to same offset and uses same
length as mentioned for input packet?

Thanks
Shally

>>
>> /**
>>  * Crypto packet API operation result
>>  */
>> typedef struct odp_crypto_packet_result_t {
>> /** Request completed successfully */
>> odp_bool_t  ok;
>>
>> /** Cipher status */
>> odp_crypto_op_status_t cipher_status;
>>
>> /** Authentication status */
>> odp_crypto_op_status_t auth_status;
>>
>> } odp_crypto_packet_result_t;
>>
>> /**
>>  * Cryto API per packet operation completion status
>>  */
>> typedef struct odp_crypto_op_status {
>> /** Algorithm specific return code */
>> odp_crypto_alg_err_t alg_err;
>>
>> /** Hardware specific return code */
>> odp_crypto_hw_err_t  hw_err;
>>
>> } odp_crypto_op_status_t;
>>
>> /**
>>  * Crypto API algorithm return code
>>  */
>> typedef enum {
>> /** Algorithm successful */
>> ODP_CRYPTO_ALG_ERR_NONE,
>> /** Invalid data block size */
>> ODP_CRYPTO_ALG_ERR_DATA_SIZE,
>> /** Key size invalid for algorithm */
>> ODP_CRYPTO_ALG_ERR_KEY_SIZE,
>> /** Computed ICV value mismatch */
>> ODP_CRYPTO_ALG_ERR_ICV_CHECK,
>> /** IV value not specified */
>> ODP_CRYPTO_ALG_ERR_IV_INVALID,
>> } odp_crypto_alg_err_t;
>>
>>
>>>
>>> 2. Current crypto version of odp_crypto_op(odp_pkt_t pkt_in[] ...)
>>> does not have two separate version for encryption and decryption where
>>> as in Compression, we added two. One for compress and another for
>>> decompress.
>>> So do we want to retain two separate flavor or unify like crypto
>>> packet based api? Ex.
>>> odp_comp_op_pkt ( ... ) OR
>>> odp_comp_compress_pkt( ...),
>>> odp_comp_decompress_pkt(),
>>> odp_comp_compress_pkt_enq() and so on...?
>>
>> Crypto has single operation, IPSEC has two operations (inbound vs outbound). 
>> So, both styles are used today. Benef

Re: [lng-odp] Regarding github pull request

[shally verma]

Hi Maxim

Can you help me to get over this  CC and Signed-off-by issues. I am
creating patches now through github pull, so where do we mention
people outside of lng-odp.

And what is this error about odp license.

Thanks
Shally

On Thu, Aug 3, 2017 at 9:39 PM, Verma, Shally <shally.ve...@cavium.com> wrote:
>
>
>
>
> From: Bill Fischofer [mailto:bill.fischo...@linaro.org]
> Sent: 03 August 2017 17:54
> To: shally verma <shallyvermacav...@gmail.com>
> Cc: Dmitry Eremin-Solenikov <dmitry.ereminsoleni...@linaro.org>; Challa,
> Mahipal <mahipal.cha...@cavium.com>; lng-odp-forward
> <lng-odp@lists.linaro.org>; Narayana, Prasad Athreya
> <prasadathreya.naray...@cavium.com>; Verma, Shally
> <shally.ve...@cavium.com>; Attunuru, Vamsi <vamsi.attun...@cavium.com>
> Subject: Re: [lng-odp] Regarding github pull request
>
>
>
> GitHub comments should be echoed to the ODP mailing list, so if you're
> subscribed you should see them.
>
>
>
> I too assumed so but it didn’t work this way. I did get PATCH email but not
> of review comments on it. I had to add my email ID to github Email settings.
>
>
>
>
>
> On Thu, Aug 3, 2017 at 12:40 AM, shally verma <shallyvermacav...@gmail.com>
> wrote:
>
> On Wed, Aug 2, 2017 at 10:04 PM, shally verma
>
> <shallyvermacav...@gmail.com> wrote:
>> On Wed, Aug 2, 2017 at 6:03 PM, Dmitry Eremin-Solenikov
>> <dmitry.ereminsoleni...@linaro.org> wrote:
>>> On 2 August 2017 at 15:18, shally verma <shallyvermacav...@gmail.com>
>>> wrote:
>>>> On Wed, Aug 2, 2017 at 4:37 PM, Maxim Uvarov <maxim.uva...@linaro.org>
>>>> wrote:
>>>>>
>>>>>
>>>>> On 2 August 2017 at 14:05, Dmitry Eremin-Solenikov
>>>>> <dmitry.ereminsoleni...@linaro.org> wrote:
>>>>>>
>>>>>> On 02/08/17 13:56, shally verma wrote:
>>>>>> > On Wed, Aug 2, 2017 at 4:15 PM, Maxim Uvarov
>>>>>> > <maxim.uva...@linaro.org>
>>>>>> > wrote:
>>>>>> >>
>>>>>> >>
>>>>>> >> On 2 August 2017 at 13:35, shally verma
>>>>>> >> <shallyvermacav...@gmail.com>
>>>>>> >> wrote:
>>>>>> >>>
>>>>>> >>> Hi
>>>>>> >>>
>>>>>> >>> Based on discussion in yesterday's odp public call, I was trying
>>>>>> >>> to
>>>>>> >>> exercise github pull request feature for patch submission. But
>>>>>> >>> running
>>>>>> >>> into some doubts.
>>>>>> >>>
>>>>>> >>> -Should I create a pull request from a main odp.git repository
>>>>>> >>> like as
>>>>>> >>> explained here
>>>>>> >>>
>>>>>> >>> https://help.github.com/articles/creating-a-pull-request-from-a-fork/
>>>>>> >>> OR from my forked repository?
>>>>>> >>>
>>>>>> >>> Ex. I forked odp.git --> 1234sv/odp, where upstream is set to
>>>>>> >>> odp.git,
>>>>>> >>> then both repos allow me to create a pull request to main odp.git
>>>>>> >>> repo
>>>>>> >>> but I dont know which way is preferred over other.
>>>>>> >>>
>>>>>> >>
>>>>>> >> pull request to main repo. Link above is correct.
>>>>>> >>
>>>>>> >>
>>>>>> >>>
>>>>>> >>> - In another email, Bill mentioned:
>>>>>> >>>
>>>>>> >>> "Every time a revision of a patch is submitted, increment the
>>>>>> >>> version.
>>>>>> >>> This
>>>>>> >>> is done automatically if you use a GitHub pull request, "
>>>>>> >>>
>>>>>> >>> So, if I create a pull request  where previous versions were
>>>>>> >>> manual(like in case of comp spec) then we need to mention subject
>>>>>> >>> [API-NEXT PATCH v5] on pull request edit?
>>>>>> >>
>>>>>> >>
>>>>>> >> yes, if you want to start with v5 then set this v

Re: [lng-odp] [PATCH API-NEXT v8 1/1] comp: compression spec

[shally verma]

On Tue, Aug 29, 2017 at 5:02 PM, Savolainen, Petri (Nokia - FI/Espoo)
<petri.savolai...@nokia.com> wrote:
>
>
>> -Original Message-----
>> From: shally verma [mailto:shallyvermacav...@gmail.com]
>> Sent: Tuesday, August 29, 2017 10:26 AM
>> To: Narayana Prasad Athreya <pathr...@caviumnetworks.com>
>> Cc: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia.com>;
>> Github ODP bot <odp...@yandex.ru>; lng-odp@lists.linaro.org; Narayana,
>> Prasad Athreya <prasadathreya.naray...@cavium.com>; Mahipal Challa
>> <mcha...@cavium.com>; Verma, Shally <shally.ve...@cavium.com>
>> Subject: Re: [lng-odp] [PATCH API-NEXT v8 1/1] comp: compression spec
>>
>> Based on last discussion, I was reworking to add odp_comp_op_pkt ()
>> API based on Crypto design. Help me to answer with these questions:
>>
>> 1. Current crypto packet base API is not giving Error code as an
>> output to its sync version i.e. in int odp_crypto_op(const
>> odp_packet_t pkt_in[],..), I do not see where it is returning
>> odp_crypto_packet_result_t. Can anyone help?
>
> Error codes are part of operation results:
>
> /**
>  * Get crypto operation results from an crypto processed packet
>  *
>  * Successful crypto operations of all types (SYNC and ASYNC) produce packets
>  * which contain crypto result metadata. This function copies the operation
>  * results from an crypto processed packet. Event subtype of this kind of
>  * packet is ODP_EVENT_PACKET_crypto. Results are undefined if a non-crypto
>  * processed packet is passed as input.
>  *
>  * @param packet  An crypto processed packet (ODP_EVENT_PACKET_CRYPTO)
>  * @param[out]result  Pointer to operation result for output
>  *
>  * @retval  0 On success
>  * @retval <0 On failure
>  */
> int odp_crypto_result(odp_crypto_packet_result_t *result,
>   odp_packet_t packet);

Ok. That seems user need to make explicit call to this API to get
result, if he want.
So this is optional call in crypto context?

>
> /**
>  * Crypto packet API operation result
>  */
> typedef struct odp_crypto_packet_result_t {
> /** Request completed successfully */
> odp_bool_t  ok;
>
> /** Cipher status */
> odp_crypto_op_status_t cipher_status;
>
> /** Authentication status */
> odp_crypto_op_status_t auth_status;
>
> } odp_crypto_packet_result_t;
>
> /**
>  * Cryto API per packet operation completion status
>  */
> typedef struct odp_crypto_op_status {
> /** Algorithm specific return code */
> odp_crypto_alg_err_t alg_err;
>
> /** Hardware specific return code */
> odp_crypto_hw_err_t  hw_err;
>
> } odp_crypto_op_status_t;
>
> /**
>  * Crypto API algorithm return code
>  */
> typedef enum {
> /** Algorithm successful */
> ODP_CRYPTO_ALG_ERR_NONE,
> /** Invalid data block size */
> ODP_CRYPTO_ALG_ERR_DATA_SIZE,
> /** Key size invalid for algorithm */
> ODP_CRYPTO_ALG_ERR_KEY_SIZE,
> /** Computed ICV value mismatch */
> ODP_CRYPTO_ALG_ERR_ICV_CHECK,
> /** IV value not specified */
> ODP_CRYPTO_ALG_ERR_IV_INVALID,
> } odp_crypto_alg_err_t;
>
>
>>
>> 2. Current crypto version of odp_crypto_op(odp_pkt_t pkt_in[] ...)
>> does not have two separate version for encryption and decryption where
>> as in Compression, we added two. One for compress and another for
>> decompress.
>> So do we want to retain two separate flavor or unify like crypto
>> packet based api? Ex.
>> odp_comp_op_pkt ( ... ) OR
>> odp_comp_compress_pkt( ...),
>> odp_comp_decompress_pkt(),
>> odp_comp_compress_pkt_enq() and so on...?
>
> Crypto has single operation, IPSEC has two operations (inbound vs outbound). 
> So, both styles are used today. Benefits of an operation per direction are:
> * more readable code: odp_comp_compress() vs odp_comp_op()
> * possibility to have different set of arguments (parameters) for each 
> direction. E.g. IPSEC does IP fragmentation on output direction and thus 
> needs extra parameters for that, those params are not defined on inbound 
> direction.
> * cleaner specification of different operations e.g. "... output of 
> odp_comp_compress()..." vs "... output of odp_comp_op() in compress mode "
> * easier to extend since a new feature can be added to one side without 
> changing the spec for the other side
>
>
> BTW, since most of our operations process packets, we don't need to highlight 
> it with "pkt". I'd name odp_comp_compress() for packets, and then later on 
> add odp_comp_compress_mem(), odp_comp_compress_from_mem(), etc for mem -> 
> mem, pkt -> mem operations.

Ok. no issues. I will retain separate flavor and keep API name in sync
to crypto.

Thanks
Shally

>
> -Petri

[lng-odp] Regarding crypto event subtypes

[shally verma]

Hi

In order to align to crypto, I was looking to latest spec regarding
Sub-event types here :

https://github.com/Linaro/odp/blob/api-next/include/odp/api/spec/event.h ,

where I cannot see reference to any sub-event type for crypto.

So could anyone confirm if crypto will be supporting only one event -
ODP_EVENT_CRYPTO_COMPL and no subtype?

Thanks
Shally

Re: [lng-odp] [PATCH API-NEXT v8 1/1] comp: compression spec

[shally verma]

Based on last discussion, I was reworking to add odp_comp_op_pkt ()
API based on Crypto design. Help me to answer with these questions:

1. Current crypto packet base API is not giving Error code as an
output to its sync version i.e. in int odp_crypto_op(const
odp_packet_t pkt_in[],..), I do not see where it is returning
odp_crypto_packet_result_t. Can anyone help?

2. Current crypto version of odp_crypto_op(odp_pkt_t pkt_in[] ...)
does not have two separate version for encryption and decryption where
as in Compression, we added two. One for compress and another for
decompress.
So do we want to retain two separate flavor or unify like crypto
packet based api? Ex.
odp_comp_op_pkt ( ... ) OR
odp_comp_compress_pkt( ...),
odp_comp_decompress_pkt(),
odp_comp_compress_pkt_enq() and so on...?



Thanks
Shally

On Tue, Aug 8, 2017 at 11:36 PM, Narayana Prasad Athreya
<pathr...@caviumnetworks.com> wrote:
> Can someone explain what is the use-case of #1 and why the use-case cannot
> be met with proposed API?
>
> PRasad
>
> On Tuesday 08 August 2017 10:21 PM, shally verma wrote:
>
> Petri/Berry
>
> As per discussion in today's call, this is what I summarize :
>
> Two new requirements added:
>
> 1. Support compression / decompression of multiple ranges with in one
> single packet and
> 2. Operating on multiple packets with in call where each packet may
> further carry multiple range.
>
> To meet 1st requirement, current proposal says, calling
> odp_packet_compress/decomp() for each packet per range as it allows
> easy and clean management of output buffer and also more flexibility
> per various possible  application use cases:.
> - call can be made in statefull or stateless mode per each range, Or
> - Modify  headers according to each range output,
> - Application manage output buffers at their end,
> - Async notification on out of space condition  will be easily maintained.
>
> Currently , we do support file-based compression using ODP APIs, but
> i.e. on stream of data bytes where 1 chunk occupy - 1 packet (which
> can be segmented/unsegmented) not on stream of Packets.
> Is there a use-case to have a file which consists of stream of
> Packets? (where packet is of type HTTP Packet ?)
>
> New proposal says "allow multiple ranges with in one single call". Few
> concerns raised for this, key one include:
>
> - How do we know each range be compressed in stateful  or stateless
> mode i.e. each range is independent Or dependent?
> - How do we handle out_of_space error while operating on individual
> range? Especially for the case when Implementation try to use HW
> parallelization for better throughput?
> - How do we support same design in asynchronous mode ??
> - How do we see it  - as performance gain ? Or ease-of-use?  Or it may
> end up introducing more overhead to implementation.
>
> Please feedback your inputs to design issues as envisioned.
>
> For now we can focus on requirement #1 as design for requirement # 2
> will be based on outcome of #1.
>
> Thanks
> Shally
>
> On Tue, Aug 8, 2017 at 6:38 PM, Savolainen, Petri (Nokia - FI/Espoo)
> <petri.savolai...@nokia.com> wrote:
>
> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> Github ODP bot
> Sent: Friday, August 04, 2017 4:00 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCH API-NEXT v8 1/1] comp: compression spec
>
> From: Shally Verma <shally.ve...@cavium.com>
>
> Signed-off-by: Shally Verma <shally.ve...@cavium.com>
> Signed-off-by: Mahipal Challa <mahipal.cha...@cavium.com> Cc
> prasadathreya.naray...@cavium.com
> ---
> /** Email created from pull request 102 (1234sv:api-next)
>  ** https://github.com/Linaro/odp/pull/102
>  ** Patch: https://github.com/Linaro/odp/pull/102.patch
>  ** Base sha: 8390f890d4bd2babb63a24f7b15d2f4763e44050
>  ** Merge commit sha: fbdff8c82a19f5b640ae299204b3bb1bbbefdccb
>  **/
>  include/odp/api/spec/comp.h | 815
> 
>  1 file changed, 815 insertions(+)
>  create mode 100644 include/odp/api/spec/comp.h
>
> diff --git a/include/odp/api/spec/comp.h b/include/odp/api/spec/comp.h
> new file mode 100644
> index ..2956094c
> --- /dev/null
> +++ b/include/odp/api/spec/comp.h
> @@ -0,0 +1,815 @@
> +/* Copyright (c) 2013, Linaro Limited
>
> Year 2017
>
> +
> +/**
> + * Comp API hash algorithm
> + *
> + */
> +typedef enum {
> + /** ODP_COMP_HASH_ALG_NONE*/
>
> This kind of comment is not very helpful. Each enumeration needs explanation
> - like odp_comp_alg_t under.
>
> + ODP_COMP_HASH_ALG_NONE,
> + /** ODP_COMP_HASH_ALG_SHA1*/
> + ODP_COMP_HASH_ALG_SHA1,
> 

Re: [lng-odp] [EXT] Re: ODP1.15 buffer alignment issue

[shally verma]

just to add for some implementation Buffer == data itself (without any
metadata or headroom). So while you work on this, please get us
clarity for such implementations as well.

On Fri, Aug 11, 2017 at 12:36 AM, Maxim Uvarov  wrote:
> On 08/10/17 21:41, Liron Himi wrote:
>> Hi,
>>
>> I think it is more than just naming replacement.
>> The odp-pool API state that the alignment is for buffer alignment and not 
>> for data. So it seems like a bug, right?
>>
>> Here is a snipped from the API:
>>   /** Minimum buffer alignment in bytes. Valid values are
>>   powers of two. Use 0 for default alignment.
>>   Default will always be a multiple of 8. */
>>   uint32_t align;
>>   } buf;
>>
>> Regards,
>> Liron
>>
>
>
> Ok, in my understanding this value comes from:
>
> typedef struct odp_pool_capability_t {
> .
>
> /** Buffer pool capabilities  */
> struct {
> /** Maximum buffer data alignment in bytes */
> uint32_t max_align;
>
>
> So it has to be "buffer data alignment". Please give me some time to
> double check with community that we all understand this api definition
> right.
>
> Thank you,
> Maxim.
>
>
>> -Original Message-
>> From: Maxim Uvarov [mailto:maxim.uva...@linaro.org]
>> Sent: Thursday, August 10, 2017 19:45
>> To: Liron Himi ; lng-odp@lists.linaro.org
>> Cc: Petri Savolainen ; Elo, Matias (Nokia - 
>> FI/Espoo) 
>> Subject: [EXT] Re: [lng-odp] ODP1.15 buffer alignment issue
>>
>> External Email
>>
>> --
>> On 08/08/17 09:49, Liron Himi wrote:
>>> Hi,
>>>
>>> See comments inline
>>>
>>> Regards,
>>> Liron
>>>
>>> -Original Message-
>>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>>> Maxim Uvarov
>>> Sent: Monday, August 07, 2017 23:21
>>> To: lng-odp@lists.linaro.org
>>> Subject: Re: [lng-odp] ODP1.15 buffer alignment issue
>>>
>>> it's implementation specific.
>>>
>>> Full code is:
>>>
>>> +   offset = pool->headroom;
>>> +
>>> +   /* move to correct align */
>>> +   while (((uintptr_t)[offset]) % pool->align != 0)
>>> +   offset++;
>>> 
>>> +
>>> +   /* Pointer to data start (of the first segment) */
>>> +   buf_hdr->addr[0] = [offset];
>>> +   /* Store buffer into the global pool */
>>> +   ring_enq(ring, mask, (uint32_t)(uintptr_t)buf_hdl);
>>>
>>> If I understood idea right there should be odp specific packet header with 
>>> odp fields which is needed to implement api but missing in hardware buffer 
>>> field. Then hw buffer which is aligned by default with pointer to data. 
>>> Everything depends on implementation and it's not mandatory.
>>> [L.H.] As part of the linux-generic there is a 
>>> 'ODP_CONFIG_BUFFER_ALIGN_MIN' which should be used for the buffer alignment.
>>> However, the code above use this value for the data section alignment in 
>>> the buffer and not the buffer address alignment.
>>> On ODP1.11 the 'ODP_CONFIG_BUFFER_ALIGN_MIN' was used correctly for buffer 
>>> alignment.
>>> In order to continue we need to understand what was the real intention here:
>>> 1. To make sure the data section is aligned?
>>> 2. To make sure the buffer address is aligned? If so, there is a bug in 
>>> this code. A possible fix is as follow:
>>>  -   offset = pool->headroom;
>>>  +   offset = 0;
>>>
>>>  /* move to correct align */
>>> while (((uintptr_t)[offset]) % pool->align != 0)
>>> offset++;
>>>  +   offset += pool->headroom
>>>  
>>>  /* Pointer to data start (of the first segment) */
>>> buf_hdr->addr[0] = [offset];
>>>
>>> If 1# is required than maybe a 'ODP_CONFIG_DATA_ALIGN_MIN' should be define.
>>>
>>
>> Ah, ok I see. I think in current code we used data align. So that rename to 
>> ODP_CONFIG_DATA_ALIGN_MIN is needed. The remain question is should we also 
>> align buffers itself.
>>
>> Petri, Matias can you please test with dpdk pktio if buffer alignment 
>> improves performance?
>>
>> Maxim.
>>
>>
>>
>>> If your platform reuses this linux-generic file and that alignment does not 
>>> work for you then we rework it somehow.
>>>
>>> Bet regards.
>>> Maxim.
>>>
>>>
>>> On 08/07/17 21:58, Bill Fischofer wrote:
 This is part of the latest pool restructure code contributed by Nokia.
 If you'd like to join the ODP public call tomorrow at 15:00 UTC we
 can discuss this then.

 On Mon, Aug 7, 2017 at 8:57 AM, Liron Himi  wrote:

> Hi,
>
> I'm trying to move to odp1.15 and encounter with an buffer alignment 
> issue.
> It 

Re: [lng-odp] [PATCH API-NEXT v8 1/1] comp: compression spec

[shally verma]

Just a Resend.

On Tue, Aug 8, 2017 at 10:21 PM, shally verma
<shallyvermacav...@gmail.com> wrote:
> Petri/Berry
>
> As per discussion in today's call, this is what I summarize :
>
> Two new requirements added:
>
> 1. Support compression / decompression of multiple ranges with in one
> single packet and
> 2. Operating on multiple packets with in call where each packet may
> further carry multiple range.
>
> To meet 1st requirement, current proposal says, calling
> odp_packet_compress/decomp() for each packet per range as it allows
> easy and clean management of output buffer and also more flexibility
> per various possible  application use cases:.
> - call can be made in statefull or stateless mode per each range, Or
> - Modify  headers according to each range output,
> - Application manage output buffers at their end,
> - Async notification on out of space condition  will be easily maintained.
>
> Currently , we do support file-based compression using ODP APIs, but
> i.e. on stream of data bytes where 1 chunk occupy - 1 packet (which
> can be segmented/unsegmented) not on stream of Packets.
> Is there a use-case to have a file which consists of stream of
> Packets? (where packet is of type HTTP Packet ?)
>
> New proposal says "allow multiple ranges with in one single call". Few
> concerns raised for this, key one include:
>
> - How do we know each range be compressed in stateful  or stateless
> mode i.e. each range is independent Or dependent?
> - How do we handle out_of_space error while operating on individual
> range? Especially for the case when Implementation try to use HW
> parallelization for better throughput?
> - How do we support same design in asynchronous mode ??
> - How do we see it  - as performance gain ? Or ease-of-use?  Or it may
> end up introducing more overhead to implementation.
>
> Please feedback your inputs to design issues as envisioned.
>
> For now we can focus on requirement #1 as design for requirement # 2
> will be based on outcome of #1.
>
> Thanks
> Shally
>
> On Tue, Aug 8, 2017 at 6:38 PM, Savolainen, Petri (Nokia - FI/Espoo)
> <petri.savolai...@nokia.com> wrote:
>>
>>
>>> -Original Message-
>>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>>> Github ODP bot
>>> Sent: Friday, August 04, 2017 4:00 PM
>>> To: lng-odp@lists.linaro.org
>>> Subject: [lng-odp] [PATCH API-NEXT v8 1/1] comp: compression spec
>>>
>>> From: Shally Verma <shally.ve...@cavium.com>
>>>
>>> Signed-off-by: Shally Verma <shally.ve...@cavium.com>
>>> Signed-off-by: Mahipal Challa <mahipal.cha...@cavium.com> Cc
>>> prasadathreya.naray...@cavium.com
>>> ---
>>> /** Email created from pull request 102 (1234sv:api-next)
>>>  ** https://github.com/Linaro/odp/pull/102
>>>  ** Patch: https://github.com/Linaro/odp/pull/102.patch
>>>  ** Base sha: 8390f890d4bd2babb63a24f7b15d2f4763e44050
>>>  ** Merge commit sha: fbdff8c82a19f5b640ae299204b3bb1bbbefdccb
>>>  **/
>>>  include/odp/api/spec/comp.h | 815
>>> 
>>>  1 file changed, 815 insertions(+)
>>>  create mode 100644 include/odp/api/spec/comp.h
>>>
>>> diff --git a/include/odp/api/spec/comp.h b/include/odp/api/spec/comp.h
>>> new file mode 100644
>>> index ..2956094c
>>> --- /dev/null
>>> +++ b/include/odp/api/spec/comp.h
>>> @@ -0,0 +1,815 @@
>>> +/* Copyright (c) 2013, Linaro Limited
>>
>> Year 2017
>>
>>> +
>>> +/**
>>> + * Comp API hash algorithm
>>> + *
>>> + */
>>> +typedef enum {
>>> + /** ODP_COMP_HASH_ALG_NONE*/
>>
>> This kind of comment is not very helpful. Each enumeration needs explanation 
>> - like odp_comp_alg_t under.
>>
>>> + ODP_COMP_HASH_ALG_NONE,
>>> + /** ODP_COMP_HASH_ALG_SHA1*/
>>> + ODP_COMP_HASH_ALG_SHA1,
>>> + /**  ODP_COMP_HASH_ALG_SHA256*/
>>> + ODP_COMP_HASH_ALG_SHA256
>>> +} odp_comp_hash_alg_t;
>>> +
>>> +/**
>>> + * Comp API compression algorithm
>>> + *
>>> + */
>>> +typedef enum {
>>> + /** No algorithm specified.
>>> +  * Means no compression, output == input.
>>> +  * if provided, no operation (compression/decompression or
>>> hash)
>>> +  * applied on input. Added for testing purpose.
>>> +  */
>>> + ODP_COMP_ALG_NULL,
>>> + /** DEFLATE - RFC1951 *

Re: [lng-odp] [PATCH API-NEXT v8 1/1] comp: compression spec

[shally verma]

Petri/Berry

As per discussion in today's call, this is what I summarize :

Two new requirements added:

1. Support compression / decompression of multiple ranges with in one
single packet and
2. Operating on multiple packets with in call where each packet may
further carry multiple range.

To meet 1st requirement, current proposal says, calling
odp_packet_compress/decomp() for each packet per range as it allows
easy and clean management of output buffer and also more flexibility
per various possible  application use cases:.
- call can be made in statefull or stateless mode per each range, Or
- Modify  headers according to each range output,
- Application manage output buffers at their end,
- Async notification on out of space condition  will be easily maintained.

Currently , we do support file-based compression using ODP APIs, but
i.e. on stream of data bytes where 1 chunk occupy - 1 packet (which
can be segmented/unsegmented) not on stream of Packets.
Is there a use-case to have a file which consists of stream of
Packets? (where packet is of type HTTP Packet ?)

New proposal says "allow multiple ranges with in one single call". Few
concerns raised for this, key one include:

- How do we know each range be compressed in stateful  or stateless
mode i.e. each range is independent Or dependent?
- How do we handle out_of_space error while operating on individual
range? Especially for the case when Implementation try to use HW
parallelization for better throughput?
- How do we support same design in asynchronous mode ??
- How do we see it  - as performance gain ? Or ease-of-use?  Or it may
end up introducing more overhead to implementation.

Please feedback your inputs to design issues as envisioned.

For now we can focus on requirement #1 as design for requirement # 2
will be based on outcome of #1.

Thanks
Shally

On Tue, Aug 8, 2017 at 6:38 PM, Savolainen, Petri (Nokia - FI/Espoo)
<petri.savolai...@nokia.com> wrote:
>
>
>> -Original Message-
>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>> Github ODP bot
>> Sent: Friday, August 04, 2017 4:00 PM
>> To: lng-odp@lists.linaro.org
>> Subject: [lng-odp] [PATCH API-NEXT v8 1/1] comp: compression spec
>>
>> From: Shally Verma <shally.ve...@cavium.com>
>>
>> Signed-off-by: Shally Verma <shally.ve...@cavium.com>
>> Signed-off-by: Mahipal Challa <mahipal.cha...@cavium.com> Cc
>> prasadathreya.naray...@cavium.com
>> ---
>> /** Email created from pull request 102 (1234sv:api-next)
>>  ** https://github.com/Linaro/odp/pull/102
>>  ** Patch: https://github.com/Linaro/odp/pull/102.patch
>>  ** Base sha: 8390f890d4bd2babb63a24f7b15d2f4763e44050
>>  ** Merge commit sha: fbdff8c82a19f5b640ae299204b3bb1bbbefdccb
>>  **/
>>  include/odp/api/spec/comp.h | 815
>> 
>>  1 file changed, 815 insertions(+)
>>  create mode 100644 include/odp/api/spec/comp.h
>>
>> diff --git a/include/odp/api/spec/comp.h b/include/odp/api/spec/comp.h
>> new file mode 100644
>> index ..2956094c
>> --- /dev/null
>> +++ b/include/odp/api/spec/comp.h
>> @@ -0,0 +1,815 @@
>> +/* Copyright (c) 2013, Linaro Limited
>
> Year 2017
>
>> +
>> +/**
>> + * Comp API hash algorithm
>> + *
>> + */
>> +typedef enum {
>> + /** ODP_COMP_HASH_ALG_NONE*/
>
> This kind of comment is not very helpful. Each enumeration needs explanation 
> - like odp_comp_alg_t under.
>
>> + ODP_COMP_HASH_ALG_NONE,
>> + /** ODP_COMP_HASH_ALG_SHA1*/
>> + ODP_COMP_HASH_ALG_SHA1,
>> + /**  ODP_COMP_HASH_ALG_SHA256*/
>> + ODP_COMP_HASH_ALG_SHA256
>> +} odp_comp_hash_alg_t;
>> +
>> +/**
>> + * Comp API compression algorithm
>> + *
>> + */
>> +typedef enum {
>> + /** No algorithm specified.
>> +  * Means no compression, output == input.
>> +  * if provided, no operation (compression/decompression or
>> hash)
>> +  * applied on input. Added for testing purpose.
>> +  */
>> + ODP_COMP_ALG_NULL,
>> + /** DEFLATE - RFC1951 */
>> + ODP_COMP_ALG_DEFLATE,
>> + /** ZLIB - RFC1950 */
>> + ODP_COMP_ALG_ZLIB,
>> + /** LZS */
>> + ODP_COMP_ALG_LZS
>> +} odp_comp_alg_t;
>> +
>> +
>> +/**
>> + * Hash algorithms in a bit field structure
>> + *
>> + */
>> +typedef union odp_comp_hash_algos_t {
>> + /** hash algorithms */
>> + struct {
>> + /** SHA-1 */
>> + uint32_t sha1  : 1;
>> +
>> + /** SHA with 256 bits of Message Digest */
>

Re: [lng-odp] Regarding github pull request

[shally verma]

On Wed, Aug 2, 2017 at 10:04 PM, shally verma
<shallyvermacav...@gmail.com> wrote:
> On Wed, Aug 2, 2017 at 6:03 PM, Dmitry Eremin-Solenikov
> <dmitry.ereminsoleni...@linaro.org> wrote:
>> On 2 August 2017 at 15:18, shally verma <shallyvermacav...@gmail.com> wrote:
>>> On Wed, Aug 2, 2017 at 4:37 PM, Maxim Uvarov <maxim.uva...@linaro.org> 
>>> wrote:
>>>>
>>>>
>>>> On 2 August 2017 at 14:05, Dmitry Eremin-Solenikov
>>>> <dmitry.ereminsoleni...@linaro.org> wrote:
>>>>>
>>>>> On 02/08/17 13:56, shally verma wrote:
>>>>> > On Wed, Aug 2, 2017 at 4:15 PM, Maxim Uvarov <maxim.uva...@linaro.org>
>>>>> > wrote:
>>>>> >>
>>>>> >>
>>>>> >> On 2 August 2017 at 13:35, shally verma <shallyvermacav...@gmail.com>
>>>>> >> wrote:
>>>>> >>>
>>>>> >>> Hi
>>>>> >>>
>>>>> >>> Based on discussion in yesterday's odp public call, I was trying to
>>>>> >>> exercise github pull request feature for patch submission. But running
>>>>> >>> into some doubts.
>>>>> >>>
>>>>> >>> -Should I create a pull request from a main odp.git repository like as
>>>>> >>> explained here
>>>>> >>> https://help.github.com/articles/creating-a-pull-request-from-a-fork/
>>>>> >>> OR from my forked repository?
>>>>> >>>
>>>>> >>> Ex. I forked odp.git --> 1234sv/odp, where upstream is set to odp.git,
>>>>> >>> then both repos allow me to create a pull request to main odp.git repo
>>>>> >>> but I dont know which way is preferred over other.
>>>>> >>>
>>>>> >>
>>>>> >> pull request to main repo. Link above is correct.
>>>>> >>
>>>>> >>
>>>>> >>>
>>>>> >>> - In another email, Bill mentioned:
>>>>> >>>
>>>>> >>> "Every time a revision of a patch is submitted, increment the version.
>>>>> >>> This
>>>>> >>> is done automatically if you use a GitHub pull request, "
>>>>> >>>
>>>>> >>> So, if I create a pull request  where previous versions were
>>>>> >>> manual(like in case of comp spec) then we need to mention subject
>>>>> >>> [API-NEXT PATCH v5] on pull request edit?
>>>>> >>
>>>>> >>
>>>>> >> yes, if you want to start with v5 then set this version in subject of
>>>>> >> pool
>>>>> >> request.
>>>>> >>
>>>>> > I just created sample pull request with Subject [API-NEXT PATCH v5]
>>>>> > but it changed to [PATCH API-NEXT v6] followed by my subject . So it
>>>>> > look like:
>>>>> >
>>>>> > [PATCH API-NEXT v6] comp: compression spec.
>>>>>
>>>>> Version will autoincrement on each pull request update (initial
>>>>> submission also counts). So, if you would like to send your PR as v5,
>>>>> please change title now to v5. If you will push an update, title will
>>>>> automatically be updated to v6
>>>>>
>>>>> > Also I did not get any email for same. Something is pending?
>>>>>
>>>>> Yes. Maxim's script sends e-mails hourly.
>>>>>
>>>>> > How do we add other intended recipient to this patch ? outside of
>>>>> > lng-odp list?
>>>>>
>>>>> Use Cc tags in individual patches. Maxim, will Cc tags work in cover
>>>>> e-mail/PR description?
>>>>>
>>>>
>>>> yes, they have to work.
>>>>
>>> An example would help here. Like if I do "git commit -m "Some message"
>>> cc=shallyvermacav...@gmail.com (i dont see 'cc' as git commit
>>> option')??
>>> Or what am I missing here?
>>
>> Just put Cc: somebody <some.em...@example.net> near your signed-off in
>> the commit message.
>>
> Ok. But email is sent now. Any ways that we can add people now to
> watch for further review comments on this?
>
Also. I can see review comments on login to github, but not in my mail
box. Don't we get any notification into our mail box on every review
input?

Thanks
Shally
>>>
>>> Thanks
>>> Shally
>>>
>>>>>
>>>>> >
>>>>> > Thanks
>>>>> > Shally
>>>>> >
>>>>> >>>
>>>>> >>>
>>>>> >>> - When email is sent to lng-odp after pull request, will it use github
>>>>> >>> account? if yes, do I need to subscribe that account to lng-odp? Say
>>>>> >>> my current github account is 1234sv and subscribed account is gmail
>>>>> >>> account, which of them will be used?
>>>>> >>
>>>>> >>
>>>>> >> Email will be sent from ODP bot email account. Original author of
>>>>> >> patches
>>>>> >> will be inside patches. Actually you don't need to do anything with
>>>>> >> that.
>>>>> >>
>>>>> >>
>>>>> >>>
>>>>> >>>
>>>>> >>> Any inputs would help!
>>>>> >>>
>>>>> >>> Thanks
>>>>> >>> Shally
>>>>> >>
>>>>> >>
>>>>>
>>>>>
>>>>> --
>>>>> With best wishes
>>>>> Dmitry
>>>>
>>>>
>>
>>
>>
>> --
>> With best wishes
>> Dmitry

Re: [lng-odp] Regarding github pull request

[shally verma]

On Wed, Aug 2, 2017 at 6:03 PM, Dmitry Eremin-Solenikov
<dmitry.ereminsoleni...@linaro.org> wrote:
> On 2 August 2017 at 15:18, shally verma <shallyvermacav...@gmail.com> wrote:
>> On Wed, Aug 2, 2017 at 4:37 PM, Maxim Uvarov <maxim.uva...@linaro.org> wrote:
>>>
>>>
>>> On 2 August 2017 at 14:05, Dmitry Eremin-Solenikov
>>> <dmitry.ereminsoleni...@linaro.org> wrote:
>>>>
>>>> On 02/08/17 13:56, shally verma wrote:
>>>> > On Wed, Aug 2, 2017 at 4:15 PM, Maxim Uvarov <maxim.uva...@linaro.org>
>>>> > wrote:
>>>> >>
>>>> >>
>>>> >> On 2 August 2017 at 13:35, shally verma <shallyvermacav...@gmail.com>
>>>> >> wrote:
>>>> >>>
>>>> >>> Hi
>>>> >>>
>>>> >>> Based on discussion in yesterday's odp public call, I was trying to
>>>> >>> exercise github pull request feature for patch submission. But running
>>>> >>> into some doubts.
>>>> >>>
>>>> >>> -Should I create a pull request from a main odp.git repository like as
>>>> >>> explained here
>>>> >>> https://help.github.com/articles/creating-a-pull-request-from-a-fork/
>>>> >>> OR from my forked repository?
>>>> >>>
>>>> >>> Ex. I forked odp.git --> 1234sv/odp, where upstream is set to odp.git,
>>>> >>> then both repos allow me to create a pull request to main odp.git repo
>>>> >>> but I dont know which way is preferred over other.
>>>> >>>
>>>> >>
>>>> >> pull request to main repo. Link above is correct.
>>>> >>
>>>> >>
>>>> >>>
>>>> >>> - In another email, Bill mentioned:
>>>> >>>
>>>> >>> "Every time a revision of a patch is submitted, increment the version.
>>>> >>> This
>>>> >>> is done automatically if you use a GitHub pull request, "
>>>> >>>
>>>> >>> So, if I create a pull request  where previous versions were
>>>> >>> manual(like in case of comp spec) then we need to mention subject
>>>> >>> [API-NEXT PATCH v5] on pull request edit?
>>>> >>
>>>> >>
>>>> >> yes, if you want to start with v5 then set this version in subject of
>>>> >> pool
>>>> >> request.
>>>> >>
>>>> > I just created sample pull request with Subject [API-NEXT PATCH v5]
>>>> > but it changed to [PATCH API-NEXT v6] followed by my subject . So it
>>>> > look like:
>>>> >
>>>> > [PATCH API-NEXT v6] comp: compression spec.
>>>>
>>>> Version will autoincrement on each pull request update (initial
>>>> submission also counts). So, if you would like to send your PR as v5,
>>>> please change title now to v5. If you will push an update, title will
>>>> automatically be updated to v6
>>>>
>>>> > Also I did not get any email for same. Something is pending?
>>>>
>>>> Yes. Maxim's script sends e-mails hourly.
>>>>
>>>> > How do we add other intended recipient to this patch ? outside of
>>>> > lng-odp list?
>>>>
>>>> Use Cc tags in individual patches. Maxim, will Cc tags work in cover
>>>> e-mail/PR description?
>>>>
>>>
>>> yes, they have to work.
>>>
>> An example would help here. Like if I do "git commit -m "Some message"
>> cc=shallyvermacav...@gmail.com (i dont see 'cc' as git commit
>> option')??
>> Or what am I missing here?
>
> Just put Cc: somebody <some.em...@example.net> near your signed-off in
> the commit message.
>
Ok. But email is sent now. Any ways that we can add people now to
watch for further review comments on this?

>>
>> Thanks
>> Shally
>>
>>>>
>>>> >
>>>> > Thanks
>>>> > Shally
>>>> >
>>>> >>>
>>>> >>>
>>>> >>> - When email is sent to lng-odp after pull request, will it use github
>>>> >>> account? if yes, do I need to subscribe that account to lng-odp? Say
>>>> >>> my current github account is 1234sv and subscribed account is gmail
>>>> >>> account, which of them will be used?
>>>> >>
>>>> >>
>>>> >> Email will be sent from ODP bot email account. Original author of
>>>> >> patches
>>>> >> will be inside patches. Actually you don't need to do anything with
>>>> >> that.
>>>> >>
>>>> >>
>>>> >>>
>>>> >>>
>>>> >>> Any inputs would help!
>>>> >>>
>>>> >>> Thanks
>>>> >>> Shally
>>>> >>
>>>> >>
>>>>
>>>>
>>>> --
>>>> With best wishes
>>>> Dmitry
>>>
>>>
>
>
>
> --
> With best wishes
> Dmitry

Re: [lng-odp] Regarding github pull request

[shally verma]

On Wed, Aug 2, 2017 at 4:37 PM, Maxim Uvarov <maxim.uva...@linaro.org> wrote:
>
>
> On 2 August 2017 at 14:05, Dmitry Eremin-Solenikov
> <dmitry.ereminsoleni...@linaro.org> wrote:
>>
>> On 02/08/17 13:56, shally verma wrote:
>> > On Wed, Aug 2, 2017 at 4:15 PM, Maxim Uvarov <maxim.uva...@linaro.org>
>> > wrote:
>> >>
>> >>
>> >> On 2 August 2017 at 13:35, shally verma <shallyvermacav...@gmail.com>
>> >> wrote:
>> >>>
>> >>> Hi
>> >>>
>> >>> Based on discussion in yesterday's odp public call, I was trying to
>> >>> exercise github pull request feature for patch submission. But running
>> >>> into some doubts.
>> >>>
>> >>> -Should I create a pull request from a main odp.git repository like as
>> >>> explained here
>> >>> https://help.github.com/articles/creating-a-pull-request-from-a-fork/
>> >>> OR from my forked repository?
>> >>>
>> >>> Ex. I forked odp.git --> 1234sv/odp, where upstream is set to odp.git,
>> >>> then both repos allow me to create a pull request to main odp.git repo
>> >>> but I dont know which way is preferred over other.
>> >>>
>> >>
>> >> pull request to main repo. Link above is correct.
>> >>
>> >>
>> >>>
>> >>> - In another email, Bill mentioned:
>> >>>
>> >>> "Every time a revision of a patch is submitted, increment the version.
>> >>> This
>> >>> is done automatically if you use a GitHub pull request, "
>> >>>
>> >>> So, if I create a pull request  where previous versions were
>> >>> manual(like in case of comp spec) then we need to mention subject
>> >>> [API-NEXT PATCH v5] on pull request edit?
>> >>
>> >>
>> >> yes, if you want to start with v5 then set this version in subject of
>> >> pool
>> >> request.
>> >>
>> > I just created sample pull request with Subject [API-NEXT PATCH v5]
>> > but it changed to [PATCH API-NEXT v6] followed by my subject . So it
>> > look like:
>> >
>> > [PATCH API-NEXT v6] comp: compression spec.
>>
>> Version will autoincrement on each pull request update (initial
>> submission also counts). So, if you would like to send your PR as v5,
>> please change title now to v5. If you will push an update, title will
>> automatically be updated to v6
>>
>> > Also I did not get any email for same. Something is pending?
>>
>> Yes. Maxim's script sends e-mails hourly.
>>
>> > How do we add other intended recipient to this patch ? outside of
>> > lng-odp list?
>>
>> Use Cc tags in individual patches. Maxim, will Cc tags work in cover
>> e-mail/PR description?
>>
>
> yes, they have to work.
>
An example would help here. Like if I do "git commit -m "Some message"
cc=shallyvermacav...@gmail.com (i dont see 'cc' as git commit
option')??
Or what am I missing here?

Thanks
Shally

>>
>> >
>> > Thanks
>> > Shally
>> >
>> >>>
>> >>>
>> >>> - When email is sent to lng-odp after pull request, will it use github
>> >>> account? if yes, do I need to subscribe that account to lng-odp? Say
>> >>> my current github account is 1234sv and subscribed account is gmail
>> >>> account, which of them will be used?
>> >>
>> >>
>> >> Email will be sent from ODP bot email account. Original author of
>> >> patches
>> >> will be inside patches. Actually you don't need to do anything with
>> >> that.
>> >>
>> >>
>> >>>
>> >>>
>> >>> Any inputs would help!
>> >>>
>> >>> Thanks
>> >>> Shally
>> >>
>> >>
>>
>>
>> --
>> With best wishes
>> Dmitry
>
>

Re: [lng-odp] Regarding github pull request

[shally verma]

On Wed, Aug 2, 2017 at 4:15 PM, Maxim Uvarov <maxim.uva...@linaro.org> wrote:
>
>
> On 2 August 2017 at 13:35, shally verma <shallyvermacav...@gmail.com> wrote:
>>
>> Hi
>>
>> Based on discussion in yesterday's odp public call, I was trying to
>> exercise github pull request feature for patch submission. But running
>> into some doubts.
>>
>> -Should I create a pull request from a main odp.git repository like as
>> explained here
>> https://help.github.com/articles/creating-a-pull-request-from-a-fork/
>> OR from my forked repository?
>>
>> Ex. I forked odp.git --> 1234sv/odp, where upstream is set to odp.git,
>> then both repos allow me to create a pull request to main odp.git repo
>> but I dont know which way is preferred over other.
>>
>
> pull request to main repo. Link above is correct.
>
>
>>
>> - In another email, Bill mentioned:
>>
>> "Every time a revision of a patch is submitted, increment the version.
>> This
>> is done automatically if you use a GitHub pull request, "
>>
>> So, if I create a pull request  where previous versions were
>> manual(like in case of comp spec) then we need to mention subject
>> [API-NEXT PATCH v5] on pull request edit?
>
>
> yes, if you want to start with v5 then set this version in subject of pool
> request.
>
I just created sample pull request with Subject [API-NEXT PATCH v5]
but it changed to [PATCH API-NEXT v6] followed by my subject . So it
look like:

[PATCH API-NEXT v6] comp: compression spec.
Also I did not get any email for same. Something is pending?
How do we add other intended recipient to this patch ? outside of lng-odp list?

Thanks
Shally

>>
>>
>> - When email is sent to lng-odp after pull request, will it use github
>> account? if yes, do I need to subscribe that account to lng-odp? Say
>> my current github account is 1234sv and subscribed account is gmail
>> account, which of them will be used?
>
>
> Email will be sent from ODP bot email account. Original author of patches
> will be inside patches. Actually you don't need to do anything with that.
>
>
>>
>>
>> Any inputs would help!
>>
>> Thanks
>> Shally
>
>

[lng-odp] Regarding github pull request

[shally verma]

Hi

Based on discussion in yesterday's odp public call, I was trying to
exercise github pull request feature for patch submission. But running
into some doubts.

-Should I create a pull request from a main odp.git repository like as
explained here 
https://help.github.com/articles/creating-a-pull-request-from-a-fork/
OR from my forked repository?

Ex. I forked odp.git --> 1234sv/odp, where upstream is set to odp.git,
then both repos allow me to create a pull request to main odp.git repo
but I dont know which way is preferred over other.

- In another email, Bill mentioned:

"Every time a revision of a patch is submitted, increment the version. This
is done automatically if you use a GitHub pull request, "

So, if I create a pull request  where previous versions were
manual(like in case of comp spec) then we need to mention subject
[API-NEXT PATCH v5] on pull request edit?

- When email is sent to lng-odp after pull request, will it use github
account? if yes, do I need to subscribe that account to lng-odp? Say
my current github account is 1234sv and subscribed account is gmail
account, which of them will be used?

Any inputs would help!

Thanks
Shally

Re: [lng-odp] [PATCH API-NEXT v1 1/1] api:pktio: add MAC address and MTU set functions.

[shally verma]

On Wed, Aug 2, 2017 at 1:39 AM, Maxim Uvarov <maxim.uva...@linaro.org> wrote:
> On 08/01/17 15:02, Bill Fischofer wrote:
>> Correct tag for this should be --subject-prefix="API-NEXT PATCHv2"
>>
>> Every time a revision of a patch is submitted, increment the version. This
>> is done automatically if you use a GitHub pull request, but must be done
>> manually if you submit the patch via e-mail.
>>
>> Thanks.
>>
>> On Tue, Aug 1, 2017 at 2:38 AM, Vamsi Attunuru <vamsi.cav...@gmail.com>
>> wrote:
>>
>>> Signed-off-by: Vamsi Attunuru <vattun...@cavium.com>
>>> Signed-off-by: Shally Verma   <sve...@cavium.com>
>>> Signed-off-by: Mahipal Challa <mcha...@cavium.com>
>>>
>>> ---
>>>  include/odp/api/spec/packet_io.h | 167 ++
>>> +
>>>  1 file changed, 167 insertions(+)
>>>
>>> diff --git a/include/odp/api/spec/packet_io.h
>>> b/include/odp/api/spec/packet_io.h
>>> index 8802089..7174c0f 100644
>>> --- a/include/odp/api/spec/packet_io.h
>>> +++ b/include/odp/api/spec/packet_io.h
>>> @@ -451,6 +451,16 @@ typedef union odp_pktio_set_op_t {
>>> struct {
>>> /** Promiscuous mode */
>>> uint32_t promisc_mode : 1;
>>> +   /** Allow default MAC address to be set */
>>> +   uint32_t mac_addr_set : 1;
>>> +   /** Allow multiple addresses to be added
>>> + * other than default. When enabled, app
>>> + * can call odp_mac_addr_add API to set
>>> + * mac addresses upto the limit indicated by
>>> + * Odp_pktio_capability_t:max_mac_addresses */
>>> +   uint32_t mac_addr_add : 1;
>>> +   /** Allow app to set MTU size */
>>> +   uint32_t mtu_set : 1;
>>> } op;
>>> /** All bits of the bit field structure.
>>>   * This field can be used to set/clear all flags, or bitwise
>>> @@ -459,6 +469,71 @@ typedef union odp_pktio_set_op_t {
>>>  } odp_pktio_set_op_t;
>>>
>>>  /**
>>> + * MAC address type
>>> + */
>>> +typedef enum odp_mac_addr_type_t {
>>> +   /** Unicast MAC address type */
>>> +   ODP_MAC_ADDR_TYPE_UCAST = 0,
>>> +
>>> +   /** Multicast MAC address type */
>>> +   ODP_MAC_ADDR_TYPE_BCAST
>>> +} odp_mac_addr_type_t;
>>> +
>
> is that needed? broadcast/multicast macs are known. I think we don't
> need to flag them in api.

Shally - This is not really necessary to add. We added this keeping in
mind the devices that may internally have separate tables for storing
multi and unicast addresses. Alternative is to detect which type is it
(as in example  mentioned below) and use appropriate place to store
them. For now, we can get rid of them. It was added to have more views
on  it.

>
>
>>> +/**
>>> + * MAC address add/remove operation status types
>>> + *
>>> + * These status types denote various statuses set by
>>> + * odp_pktio_mac_addr_add/remove APIs in odp_pktio_mac_addr_t:status.
>>> + */
>>> +typedef enum odp_mac_ops_status_t {
>>> +   /** MAC address add/remove is successful */
>>> +   ODP_MAC_ADDR_OP_SUCCESS = 0,
>>> +
>>> +   /** Invalid mac address passed in odp_pktio_mac_addr_t:mac_addr */
>>> +   ODP_MAC_ADDR_INVALID,
>>> +
>>> +   /** odp_pktio_mac_addr_t:mac_addr points to NULL */
>>> +   ODP_MAC_ADDR_PTR_NULL,
>>> +
>>> +   /** Entry in mac_addr_tbl[] is NULL */
>>> +   ODP_MAC_ADDR_ENTRY_NULL,
>>> +
>>> +   /** MAC address size mismatch
>>> +* odp_pktio_mac_addr_t:mac_addr_len
>>> +* != odp_pktio_capability_t:mac_addr_len */
>>> +   ODP_MAC_ADDR_SIZE_ERR,
>>> +
>>> +   /** Index is invalid,
>>> +* odp_pktio_mac_addr_t:index >= 
>>> odp_pktio_capability_t:max_mac_addresses
>>> */
>>> +   ODP_MAC_ADDR_INVALID_INDEX
>>> +} odp_mac_ops_status_t;
>>> +
>
> Then simple then better. return -1 and odp_errno set if needed. Any
> initialization time errors can be easily found while debugging. For
> runtime errors there is more reason for enum. For current case it is
> not needed.
>
>
>>> +/**
>>> + * Packet IO MAC address structure
>>>

Re: [lng-odp] regarding packet pool creation

[shally verma]

On Tue, Jul 25, 2017 at 5:02 PM, Bill Fischofer
<bill.fischo...@linaro.org> wrote:
>
>
> On Mon, Jul 24, 2017 at 7:26 AM, shally verma <shallyvermacav...@gmail.com>
> wrote:
>>
>> On Mon, Jul 24, 2017 at 5:44 PM, Bill Fischofer
>> <bill.fischo...@linaro.org> wrote:
>> > I should also point out that the pool min_seg_len does not mean that
>> > this is
>> > the minimum segment size that an application can see.
>> You mean pool_capa.pkt.min_seg_len param?
>>
>>  There are lots of ways
>> > for segments to wind up smaller than this, but mostly as a result of
>> > application actions (e.g., splitting a packet, creating references with
>> > short packets, etc.)
>> >
>>
>> Then in such case, how pool creation parameters will be referred or
>> affected. If user create pool , with seg_len = x value, and then split
>> packet then seg_len would still be same rite? How can it go below
>> .seg_len given during pool_creation time?
>
>
> Yes, the pool attributes reflect what is used when packets are initially
> drawn from a pool, however APIs like odp_packet_seg_len() and
> odp_packet_seg_data_len() return the actual number of bytes available in a
> given segment, which is always the lesser of the seg_len and the actual
> number of packet data bytes available. So, for example, a given
> implementation may use a seg_len of 256, but if the packet only has a
> packet_len of 64 then this will be reported as the available packet segment
> length since you can't address beyond packet into unused areas of segments.
> To access that you need to extend the packet head or tail using the
> appropriate ODP APIs. (e.g., odp_packet_push_head(), etc.)
>
That makes it clear.

Thanks
Shally

>>
>>
>> > On Mon, Jul 24, 2017 at 7:02 AM, Bill Fischofer
>> > <bill.fischo...@linaro.org>
>> > wrote:
>> >>
>> >> An application cannot require that an ODP implementation segment
>> >> packets.
>> >> Segmentation is a feature of some implementations and the ODP concepts
>> >> surrounding segments are there to permit application portability across
>> >> different implementations that use segmentation.
>> >>
>> >> From an application standpoint, a packet consists of a sequence of
>> >> bytes
>> >> that may be made addressable to it in one or more contiguous segments.
>> >> That's really all an application needs to know about segments. The pool
>> >> seg_len parameter is there to allow an application to provide a hint as
>> >> to
>> >> the size of the header(s) it will be processing. The intent is that all
>> >> headers of interest to the application should appear in the first
>> >> segment of
>> >> the packet. Implementations are free to use segment sizes larger than
>> >> seg_len, but if they cannot provide this minimum (seg_len is specified
>> >> too
>> >> high) then the odp_pool_create() call fails.
>> >>
>> >> If pool_capa.max_seg_len < pool_param.pkt.len then that's an indication
>> >> that such packets will be segmented in this implementation. The
>> >> odp_packet_num_seg() API will tell you how many segments are contained
>> >> in a
>> >> given odp_packet_t and this is the preferred means for an application
>> >> to get
>> >> this information.
>> >>
>> >> On Mon, Jul 24, 2017 at 6:33 AM, shally verma
>> >> <shallyvermacav...@gmail.com> wrote:
>> >>>
>> >>> Resending.
>> >>>
>> >>> On Mon, Jul 24, 2017 at 5:01 PM, shally verma
>> >>> <shallyvermacav...@gmail.com> wrote:
>> >>> > Have a question regarding packet pool creation and params. As it
>> >>> > says
>> >>> > in pool.h
>> >>> >
>> >>> > len = minimum length of pakcet
>> >>> > seg_len = minimum length of 1st segment to hold packet data bytes
>> >>> >
>> >>> > Since it says minimum, so actual segment size used to hold packet
>> >>> > data
>> >>> > size may be more than this.
>> >>> >
>> >>> > So if I want to create a packet of length say 2K bytes with 1K
>> >>> > segment
>> >>> > size where num_segs = 2, is there any ways to enforce this packet
>> >>> > structure during pool creation? Seems, it is possible only if
>> >>> > pool_capa.max_seg_len < pool_param.pkt.len
>> >>> >
>> >>> > Correct me if I am wrong here.
>> >>> >
>> >>> > Thanks
>> >>> > Shally
>> >>
>> >>
>> >
>
>

Re: [lng-odp] [PATCH API-NEXT v9 6/10] api: crypto: add crypto packet operation interface

[shally verma]

On Mon, Jul 24, 2017 at 5:55 PM, Dmitry Eremin-Solenikov
<dmitry.ereminsoleni...@linaro.org> wrote:
> On 24/07/17 15:12, shally verma wrote:
>> On Mon, Jul 24, 2017 at 5:27 PM, Dmitry Eremin-Solenikov
>> <dmitry.ereminsoleni...@linaro.org> wrote:
>>> On 24/07/17 14:11, shally verma wrote:
>>>> On Tue, Jul 11, 2017 at 7:30 PM, Github ODP bot <odp...@yandex.ru> wrote:
>>>>> From: Dmitry Eremin-Solenikov <dmitry.ereminsoleni...@linaro.org>
>>>
>>>>> @@ -311,16 +315,15 @@ typedef struct odp_crypto_session_param_t {
>>>>>
>>>>> /** Async mode completion event queue
>>>>>  *
>>>>> -*  When odp_crypto_operation() is asynchronous, the completion 
>>>>> queue is
>>>>> -*  used to return the completion status of the operation to the
>>>>> -*  application.
>>>>> +*  The completion queue is used to return 
>>>>> odp_crypto_packet_op_enq()
>>>>> +*  results to the application.
>>>>>  */
>>>>> odp_queue_t compl_queue;
>>>>>
>>>> Does it mean  "completion queue is used to return event of subtype
>>>> ODP_CRYPTO_COMPL for event of type ODP_EVENT_PACKET" ?We don't deque
>>>> result, we deque event right?
>>>
>>> Actually no. Probably I should re-clarify this. This queue can be used
>>> to deliver both ODP_CRYPTO_COMPL (if application uses
>>> odp_crypto_operation()) and ODP_EVENT_PACKET (if application uses
>>> odp_crypto_op_enq()).
>>>
>>
>> Are we keeping odp_crypto_operation() in backward compatible mode? if
>> user call this with input type as packets then it will work as
>> designated earlier (posting results to completion queue with event
>> ODP_CRYPTO_COMPL for async mode)?
>> And introducing new API odp_crypto_packet_op_enq() (not
>> *odp_crypto_op_enq()*)? which en-queue ODP_EVENT_PACKET ?
>> May be I missed some updates here.
>
> Yes, we are keeping odp_crypto_operation() for some time, because it was
> a part of API for quite some time and we would like to allow users to
> still use it, comparing it with packet interface.
>
> If application calls odp_crypto_operation() it might receive
> ODP_CRYPTO_COMPL events. If application calls odp_crypto_op_enq(), it
> will receive only ODP_EVENT_PACKET events.
>

You are referring odp_crypto_op_enq() but this patch has
odp_crypto_packet_op_enq(). so this API (odp_crypto_packet_op_enq())
not relevant?

>>
>> Shally
>>>
>>>>>  void odp_crypto_session_param_init(odp_crypto_session_param_t *param);
>>>>>
>>>>>  /**
>>>>> + * Return crypto processed packet that is associated with event
>>>>> + *
>>>>> + * Get packet handle to an crypto processed packet event. Event subtype 
>>>>> must be
>>>>> + * ODP_EVENT_PACKET_CRYPTO. Crypto operation results can be examined with
>>>>> + * odp_crypto_packet_result().
>>>>> + *
>>>>> + * Note: any invalid parameters will cause undefined behavior and may 
>>>>> cause
>>>>> + * the application to abort or crash.
>>>>> + *
>>>>> + * @param ev   Event handle
>>>>> + *
>>>>> + * @return Packet handle
>>>>> + */
>>>>> +odp_packet_t odp_crypto_packet_from_event(odp_event_t ev);
>>>>> +
>>>>
>>>> Is there any specific reason why we are not using
>>>> odp_packet_from_event() API here?
>>>> and then odp_crypto_result_from_packet()?
>>>
>>> As suggested by Petri for IPsec packets, implementation might have
>>> faster implementation for such conversion functions if it knows
>>> packet subtype.
>>>
>>> --
>>> With best wishes
>>> Dmitry
>
>
> --
> With best wishes
> Dmitry

Re: [lng-odp] regarding packet pool creation

[shally verma]

On Mon, Jul 24, 2017 at 5:44 PM, Bill Fischofer
<bill.fischo...@linaro.org> wrote:
> I should also point out that the pool min_seg_len does not mean that this is
> the minimum segment size that an application can see.
You mean pool_capa.pkt.min_seg_len param?

 There are lots of ways
> for segments to wind up smaller than this, but mostly as a result of
> application actions (e.g., splitting a packet, creating references with
> short packets, etc.)
>

Then in such case, how pool creation parameters will be referred or
affected. If user create pool , with seg_len = x value, and then split
packet then seg_len would still be same rite? How can it go below
.seg_len given during pool_creation time?

> On Mon, Jul 24, 2017 at 7:02 AM, Bill Fischofer <bill.fischo...@linaro.org>
> wrote:
>>
>> An application cannot require that an ODP implementation segment packets.
>> Segmentation is a feature of some implementations and the ODP concepts
>> surrounding segments are there to permit application portability across
>> different implementations that use segmentation.
>>
>> From an application standpoint, a packet consists of a sequence of bytes
>> that may be made addressable to it in one or more contiguous segments.
>> That's really all an application needs to know about segments. The pool
>> seg_len parameter is there to allow an application to provide a hint as to
>> the size of the header(s) it will be processing. The intent is that all
>> headers of interest to the application should appear in the first segment of
>> the packet. Implementations are free to use segment sizes larger than
>> seg_len, but if they cannot provide this minimum (seg_len is specified too
>> high) then the odp_pool_create() call fails.
>>
>> If pool_capa.max_seg_len < pool_param.pkt.len then that's an indication
>> that such packets will be segmented in this implementation. The
>> odp_packet_num_seg() API will tell you how many segments are contained in a
>> given odp_packet_t and this is the preferred means for an application to get
>> this information.
>>
>> On Mon, Jul 24, 2017 at 6:33 AM, shally verma
>> <shallyvermacav...@gmail.com> wrote:
>>>
>>> Resending.
>>>
>>> On Mon, Jul 24, 2017 at 5:01 PM, shally verma
>>> <shallyvermacav...@gmail.com> wrote:
>>> > Have a question regarding packet pool creation and params. As it says
>>> > in pool.h
>>> >
>>> > len = minimum length of pakcet
>>> > seg_len = minimum length of 1st segment to hold packet data bytes
>>> >
>>> > Since it says minimum, so actual segment size used to hold packet data
>>> > size may be more than this.
>>> >
>>> > So if I want to create a packet of length say 2K bytes with 1K segment
>>> > size where num_segs = 2, is there any ways to enforce this packet
>>> > structure during pool creation? Seems, it is possible only if
>>> > pool_capa.max_seg_len < pool_param.pkt.len
>>> >
>>> > Correct me if I am wrong here.
>>> >
>>> > Thanks
>>> > Shally
>>
>>
>

Re: [lng-odp] [PATCH API-NEXT v9 6/10] api: crypto: add crypto packet operation interface

[shally verma]

On Mon, Jul 24, 2017 at 5:27 PM, Dmitry Eremin-Solenikov
<dmitry.ereminsoleni...@linaro.org> wrote:
> On 24/07/17 14:11, shally verma wrote:
>> On Tue, Jul 11, 2017 at 7:30 PM, Github ODP bot <odp...@yandex.ru> wrote:
>>> From: Dmitry Eremin-Solenikov <dmitry.ereminsoleni...@linaro.org>
>
>>> @@ -311,16 +315,15 @@ typedef struct odp_crypto_session_param_t {
>>>
>>> /** Async mode completion event queue
>>>  *
>>> -*  When odp_crypto_operation() is asynchronous, the completion 
>>> queue is
>>> -*  used to return the completion status of the operation to the
>>> -*  application.
>>> +*  The completion queue is used to return 
>>> odp_crypto_packet_op_enq()
>>> +*  results to the application.
>>>  */
>>> odp_queue_t compl_queue;
>>>
>> Does it mean  "completion queue is used to return event of subtype
>> ODP_CRYPTO_COMPL for event of type ODP_EVENT_PACKET" ?We don't deque
>> result, we deque event right?
>
> Actually no. Probably I should re-clarify this. This queue can be used
> to deliver both ODP_CRYPTO_COMPL (if application uses
> odp_crypto_operation()) and ODP_EVENT_PACKET (if application uses
> odp_crypto_op_enq()).
>

Are we keeping odp_crypto_operation() in backward compatible mode? if
user call this with input type as packets then it will work as
designated earlier (posting results to completion queue with event
ODP_CRYPTO_COMPL for async mode)?
And introducing new API odp_crypto_packet_op_enq() (not
*odp_crypto_op_enq()*)? which en-queue ODP_EVENT_PACKET ?
May be I missed some updates here.

Shally
>
>>>  void odp_crypto_session_param_init(odp_crypto_session_param_t *param);
>>>
>>>  /**
>>> + * Return crypto processed packet that is associated with event
>>> + *
>>> + * Get packet handle to an crypto processed packet event. Event subtype 
>>> must be
>>> + * ODP_EVENT_PACKET_CRYPTO. Crypto operation results can be examined with
>>> + * odp_crypto_packet_result().
>>> + *
>>> + * Note: any invalid parameters will cause undefined behavior and may cause
>>> + * the application to abort or crash.
>>> + *
>>> + * @param ev   Event handle
>>> + *
>>> + * @return Packet handle
>>> + */
>>> +odp_packet_t odp_crypto_packet_from_event(odp_event_t ev);
>>> +
>>
>> Is there any specific reason why we are not using
>> odp_packet_from_event() API here?
>> and then odp_crypto_result_from_packet()?
>
> As suggested by Petri for IPsec packets, implementation might have
> faster implementation for such conversion functions if it knows
> packet subtype.
>
> --
> With best wishes
> Dmitry

Re: [lng-odp] regarding packet pool creation

[shally verma]

Resending.

On Mon, Jul 24, 2017 at 5:01 PM, shally verma
<shallyvermacav...@gmail.com> wrote:
> Have a question regarding packet pool creation and params. As it says in 
> pool.h
>
> len = minimum length of pakcet
> seg_len = minimum length of 1st segment to hold packet data bytes
>
> Since it says minimum, so actual segment size used to hold packet data
> size may be more than this.
>
> So if I want to create a packet of length say 2K bytes with 1K segment
> size where num_segs = 2, is there any ways to enforce this packet
> structure during pool creation? Seems, it is possible only if
> pool_capa.max_seg_len < pool_param.pkt.len
>
> Correct me if I am wrong here.
>
> Thanks
> Shally

[lng-odp] regarding packet pool creation

[shally verma]

Have a question regarding packet pool creation and params. As it says in pool.h

len = minimum length of pakcet
seg_len = minimum length of 1st segment to hold packet data bytes

Since it says minimum, so actual segment size used to hold packet data
size may be more than this.

So if I want to create a packet of length say 2K bytes with 1K segment
size where num_segs = 2, is there any ways to enforce this packet
structure during pool creation? Seems, it is possible only if
pool_capa.max_seg_len < pool_param.pkt.len

Correct me if I am wrong here.

Thanks
Shally

Re: [lng-odp] [PATCH API-NEXT v9 6/10] api: crypto: add crypto packet operation interface

[shally verma]

On Tue, Jul 11, 2017 at 7:30 PM, Github ODP bot  wrote:
> From: Dmitry Eremin-Solenikov 
>
> Input and output of crypto operations are packets. API is more flexible
> for application and API pipelining when output is packet with additional
> metadata. Application or API pipeline stages which do not care about
> crypto results may work on basic packet metadata.
>
> Crypto result event type changes from ODP_EVENT_CRYPTO_COMPL to
> ODP_EVENT_PACKET. Event subtype (ODP_EVENT_PACKET_CRYPTO) can be
> used to identify packets with crypto metadata.
>
> Signed-off-by: Dmitry Eremin-Solenikov 
> ---
> /** Email created from pull request 64 (lumag:crypto-packet)
>  ** https://github.com/Linaro/odp/pull/64
>  ** Patch: https://github.com/Linaro/odp/pull/64.patch
>  ** Base sha: c7718962c6633c80eb71a0400d89c31f11f88045
>  ** Merge commit sha: 6b4b95ac299d32801f55cf75ba31016675ac1afb
>  **/
>  example/ipsec/odp_ipsec.c  |   8 +-
>  example/ipsec/odp_ipsec_misc.h |   4 +-
>  include/odp/api/spec/crypto.h  | 176 
> +++--
>  include/odp/arch/default/api/abi/event.h   |   3 +-
>  .../include/odp/api/plat/event_types.h |   3 +-
>  5 files changed, 176 insertions(+), 18 deletions(-)
>
> diff --git a/example/ipsec/odp_ipsec.c b/example/ipsec/odp_ipsec.c
> index 1ed03585..c618cc46 100644
> --- a/example/ipsec/odp_ipsec.c
> +++ b/example/ipsec/odp_ipsec.c
> @@ -724,9 +724,9 @@ pkt_disposition_e do_ipsec_in_finish(odp_packet_t pkt,
>
> /* Check crypto result */
> if (!result->ok) {
> -   if (!is_crypto_compl_status_ok(>cipher_status))
> +   if (!is_crypto_op_status_ok(>cipher_status))
> return PKT_DROP;
> -   if (!is_crypto_compl_status_ok(>auth_status))
> +   if (!is_crypto_op_status_ok(>auth_status))
> return PKT_DROP;
> }
> ip = (odph_ipv4hdr_t *)odp_packet_l3_ptr(pkt, NULL);
> @@ -1011,9 +1011,9 @@ pkt_disposition_e do_ipsec_out_finish(odp_packet_t pkt,
>
> /* Check crypto result */
> if (!result->ok) {
> -   if (!is_crypto_compl_status_ok(>cipher_status))
> +   if (!is_crypto_op_status_ok(>cipher_status))
> return PKT_DROP;
> -   if (!is_crypto_compl_status_ok(>auth_status))
> +   if (!is_crypto_op_status_ok(>auth_status))
> return PKT_DROP;
> }
> ip = (odph_ipv4hdr_t *)odp_packet_l3_ptr(pkt, NULL);
> diff --git a/example/ipsec/odp_ipsec_misc.h b/example/ipsec/odp_ipsec_misc.h
> index 45cb022e..20ebe9fc 100644
> --- a/example/ipsec/odp_ipsec_misc.h
> +++ b/example/ipsec/odp_ipsec_misc.h
> @@ -321,12 +321,12 @@ void ipv4_adjust_len(odph_ipv4hdr_t *ip, int adj)
>  /**
>   * Verify crypto operation completed successfully
>   *
> - * @param status  Pointer to cryto completion structure
> + * @param status  Pointer to crypto op status structure
>   *
>   * @return TRUE if all OK else FALSE
>   */
>  static inline
> -odp_bool_t is_crypto_compl_status_ok(odp_crypto_compl_status_t *status)
> +odp_bool_t is_crypto_op_status_ok(odp_crypto_op_status_t *status)
>  {
> if (status->alg_err != ODP_CRYPTO_ALG_ERR_NONE)
> return FALSE;
> diff --git a/include/odp/api/spec/crypto.h b/include/odp/api/spec/crypto.h
> index b9d42937..013507f9 100644
> --- a/include/odp/api/spec/crypto.h
> +++ b/include/odp/api/spec/crypto.h
> @@ -16,6 +16,7 @@
>  #include 
>
>  #include 
> +#include 
>
>  #ifdef __cplusplus
>  extern "C" {
> @@ -276,6 +277,9 @@ typedef struct odp_crypto_session_param_t {
>  * data in non-posted mode */
> odp_crypto_op_mode_t ODP_DEPRECATE(pref_mode);
>
> +   /** Operation mode when using packet interface: sync or async */
> +   odp_crypto_op_mode_t packet_op_mode;
> +
> /** Cipher algorithm
>  *
>  *  Use odp_crypto_capability() for supported algorithms.
> @@ -311,16 +315,15 @@ typedef struct odp_crypto_session_param_t {
>
> /** Async mode completion event queue
>  *
> -*  When odp_crypto_operation() is asynchronous, the completion queue 
> is
> -*  used to return the completion status of the operation to the
> -*  application.
> +*  The completion queue is used to return odp_crypto_packet_op_enq()
> +*  results to the application.
>  */
> odp_queue_t compl_queue;
>
Does it mean  "completion queue is used to return event of subtype
ODP_CRYPTO_COMPL for event of type ODP_EVENT_PACKET" ?We don't deque
result, we deque event right?

> /** Output pool
>  *
>  *  When the output packet is not specified during the call to
> -*  odp_crypto_operation(), the output packet will be allocated
> +*  crypto operation, the 

Re: [lng-odp] Regarding odp_pktin_rcv() packets

[shally verma]

On Fri, Jul 14, 2017 at 6:06 PM, Bill Fischofer
<bill.fischo...@linaro.org> wrote:
>
>
> On Fri, Jul 14, 2017 at 6:55 AM, shally verma <shallyvermacav...@gmail.com>
> wrote:
>>
>> On Thu, Jul 13, 2017 at 2:17 PM, Savolainen, Petri (Nokia - FI/Espoo)
>> <petri.savolai...@nokia.com> wrote:
>> >
>> >
>> >> -Original Message-
>> >> From: shally verma [mailto:shallyvermacav...@gmail.com]
>> >> Sent: Thursday, July 13, 2017 11:43 AM
>> >> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia.com>
>> >> Cc: lng-odp-forward <lng-odp@lists.linaro.org>; Shally Verma
>> >> <sve...@cavium.com>
>> >> Subject: Re: [lng-odp] Regarding odp_pktin_rcv() packets
>> >>
>> >> On Thu, Jul 13, 2017 at 2:05 PM, Savolainen, Petri (Nokia - FI/Espoo)
>> >> <petri.savolai...@nokia.com> wrote:
>> >> >
>> >> >
>> >> >> -Original Message-
>> >> >> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>> >> >> shally verma
>> >> >> Sent: Wednesday, July 12, 2017 3:36 PM
>> >> >> To: lng-odp-forward <lng-odp@lists.linaro.org>; Shally Verma
>> >> >> <sve...@cavium.com>
>> >> >> Subject: [lng-odp] Regarding odp_pktin_rcv() packets
>> >> >>
>> >> >> I have a question on odp_pktin_recv(odp_pktin_queue_t, odp_packet_t
>> >> >> [],
>> >> >> int).
>> >> >>
>> >> >> Once app receives packets associated to the queue, what happens to
>> >> >> packets buffers passed to application? Does implementation always
>> >> >> assume that packets will be freed by caller and re-allocates fresh
>> >> >> packets to queue?
>> >> >>
>> >> >> I referred to packet_io.h spec to understand more on this after
>> >> >> pktin_rcv() but didn't get clear information as there seem no
>> >> >> handshake mechanism between caller and implementation to indicate
>> >> >> that
>> >> >> packet buffers are free and can be re-used. So looks like there is
>> >> >> implicit assumption that packets are not re-usable after
>> >> >> odp_pktin_rcv() call.
>> >> >>
>> >> >> Could anyone please confirm.
>> >> >>
>> >> >
>> >> > Application owns packets returned by this call (the same way as
>> >> > packets
>> >> returned by queue_deq(), schedule(), alloc() etc calls). Application
>> >> may
>> >> store those, free those (odp_packet_free()), enqueue those
>> >> (odp_queue_enq()), send those out (odp_pktout_send()), etc.
>> >> Application
>> >> owns a packet
>> >>
>> >> Agree.
>> >>
>> >> >until it calls an ODP call that takes the ownership back to the
>> >> implementation.
>> >>
>> >> So, which is this API if user want to give ownership back to pktin
>> >> interface? It is just the odp_packet_free() in case of pktio?
>> >
>> >
>> > All above take ownership: odp_packet_free(), odp_queue_enq(),
>> > odp_pktout_send() ... and many more. All ODP calls that consume a packet.
>> >
>> > It's implementation defined how packet buffers circulate back into input
>> > after free or pktout_send.
>>
>> Ok. And how it is on odp_pktout_send() , once application pass packets
>> to pktout queue, then whether implementation supposed to leave packet
>> buffer untouched once sent OR can free them?
>
>
> One you call odp_pktout_send() you no longer own that packet handle and
> should no longer refer to it. The routine will call odp_packet_free() once
> tht packet has been sent.
>

So, it seems to me an async nature of operation i.e.
odp_pktout_send() may returns after acknowledging input packets and
hardware may continue in background with actual transmission and free
whenever it is done. Is that understanding correct? if yes, then what
if any of transmission attempt fails for some reason? How does app
know about such failure.?

Shally
>>
>>
>> Thanks
>> Shally
>>
>> >
>> > -Petri
>> >
>
>

Re: [lng-odp] Regarding odp_pktin_rcv() packets

[shally verma]

On Thu, Jul 13, 2017 at 2:17 PM, Savolainen, Petri (Nokia - FI/Espoo)
<petri.savolai...@nokia.com> wrote:
>
>
>> -Original Message-----
>> From: shally verma [mailto:shallyvermacav...@gmail.com]
>> Sent: Thursday, July 13, 2017 11:43 AM
>> To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia.com>
>> Cc: lng-odp-forward <lng-odp@lists.linaro.org>; Shally Verma
>> <sve...@cavium.com>
>> Subject: Re: [lng-odp] Regarding odp_pktin_rcv() packets
>>
>> On Thu, Jul 13, 2017 at 2:05 PM, Savolainen, Petri (Nokia - FI/Espoo)
>> <petri.savolai...@nokia.com> wrote:
>> >
>> >
>> >> -Original Message-
>> >> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>> >> shally verma
>> >> Sent: Wednesday, July 12, 2017 3:36 PM
>> >> To: lng-odp-forward <lng-odp@lists.linaro.org>; Shally Verma
>> >> <sve...@cavium.com>
>> >> Subject: [lng-odp] Regarding odp_pktin_rcv() packets
>> >>
>> >> I have a question on odp_pktin_recv(odp_pktin_queue_t, odp_packet_t [],
>> >> int).
>> >>
>> >> Once app receives packets associated to the queue, what happens to
>> >> packets buffers passed to application? Does implementation always
>> >> assume that packets will be freed by caller and re-allocates fresh
>> >> packets to queue?
>> >>
>> >> I referred to packet_io.h spec to understand more on this after
>> >> pktin_rcv() but didn't get clear information as there seem no
>> >> handshake mechanism between caller and implementation to indicate that
>> >> packet buffers are free and can be re-used. So looks like there is
>> >> implicit assumption that packets are not re-usable after
>> >> odp_pktin_rcv() call.
>> >>
>> >> Could anyone please confirm.
>> >>
>> >
>> > Application owns packets returned by this call (the same way as packets
>> returned by queue_deq(), schedule(), alloc() etc calls). Application may
>> store those, free those (odp_packet_free()), enqueue those
>> (odp_queue_enq()), send those out (odp_pktout_send()), etc.  Application
>> owns a packet
>>
>> Agree.
>>
>> >until it calls an ODP call that takes the ownership back to the
>> implementation.
>>
>> So, which is this API if user want to give ownership back to pktin
>> interface? It is just the odp_packet_free() in case of pktio?
>
>
> All above take ownership: odp_packet_free(), odp_queue_enq(), 
> odp_pktout_send() ... and many more. All ODP calls that consume a packet.
>
> It's implementation defined how packet buffers circulate back into input 
> after free or pktout_send.

Ok. And how it is on odp_pktout_send() , once application pass packets
to pktout queue, then whether implementation supposed to leave packet
buffer untouched once sent OR can free them?

Thanks
Shally

>
> -Petri
>

Re: [lng-odp] Regarding odp_pktin_rcv() packets

[shally verma]

On Thu, Jul 13, 2017 at 2:05 PM, Savolainen, Petri (Nokia - FI/Espoo)
<petri.savolai...@nokia.com> wrote:
>
>
>> -Original Message-
>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>> shally verma
>> Sent: Wednesday, July 12, 2017 3:36 PM
>> To: lng-odp-forward <lng-odp@lists.linaro.org>; Shally Verma
>> <sve...@cavium.com>
>> Subject: [lng-odp] Regarding odp_pktin_rcv() packets
>>
>> I have a question on odp_pktin_recv(odp_pktin_queue_t, odp_packet_t [],
>> int).
>>
>> Once app receives packets associated to the queue, what happens to
>> packets buffers passed to application? Does implementation always
>> assume that packets will be freed by caller and re-allocates fresh
>> packets to queue?
>>
>> I referred to packet_io.h spec to understand more on this after
>> pktin_rcv() but didn't get clear information as there seem no
>> handshake mechanism between caller and implementation to indicate that
>> packet buffers are free and can be re-used. So looks like there is
>> implicit assumption that packets are not re-usable after
>> odp_pktin_rcv() call.
>>
>> Could anyone please confirm.
>>
>
> Application owns packets returned by this call (the same way as packets 
> returned by queue_deq(), schedule(), alloc() etc calls). Application may 
> store those, free those (odp_packet_free()), enqueue those (odp_queue_enq()), 
> send those out (odp_pktout_send()), etc.  Application owns a packet

Agree.

>until it calls an ODP call that takes the ownership back to the implementation.

So, which is this API if user want to give ownership back to pktin
interface? It is just the odp_packet_free() in case of pktio?

Shally

>
> -Petri
>
>

Re: [lng-odp] Regarding odp_pktin_rcv() packets

[shally verma]

On Wed, Jul 12, 2017 at 10:59 PM, Bill Fischofer
<bill.fischo...@linaro.org> wrote:
> On Wed, Jul 12, 2017 at 11:16 AM, shally verma
> <shallyvermacav...@gmail.com> wrote:
>> On Wed, Jul 12, 2017 at 8:50 PM, Bill Fischofer
>> <bill.fischo...@linaro.org> wrote:
>>> On Wed, Jul 12, 2017 at 7:35 AM, shally verma
>>> <shallyvermacav...@gmail.com> wrote:
>>>> I have a question on odp_pktin_recv(odp_pktin_queue_t, odp_packet_t [], 
>>>> int).
>>>>
>>>> Once app receives packets associated to the queue, what happens to
>>>> packets buffers passed to application? Does implementation always
>>>> assume that packets will be freed by caller and re-allocates fresh
>>>> packets to queue?
>>>
>>> Once an application receives a packet via this or any other call, e.g,
>>> odp_queue_deq(), odp_schedule(), etc., the application owns the packet
>>> and must dispose of it either by passing it on to some other entity,
>>> e.g., via odp_queue_enq(), or else freeing it via odp_packet_free().
>>> Packet lifecycle management is always explicit so there is no garbage
>>> collection for "abandoned" packets--those would be memory leaks.
>>>
>>>>
>>>> I referred to packet_io.h spec to understand more on this after
>>>> pktin_rcv() but didn't get clear information as there seem no
>>>> handshake mechanism between caller and implementation to indicate that
>>>> packet buffers are free and can be re-used. So looks like there is
>>>> implicit assumption that packets are not re-usable after
>>>> odp_pktin_rcv() call.
>>>
>>> A packet is "reused" by either passing it along to some other
>>> processing element, or else by freeing it back to its pool, from where
>>> it may be reallocated by someone else.
>>>Some APIs may consume packets
>>> and return new versions of them, in which case the free/alloc is done
>>> by the called API.
>>>
>> what do we mean by newer version here? You mean new versions are
>> returned to pktin? if so, how which API do that?
>> As for our purpose, we want to avoid free/alloc and rather reuse once
>> application has used them. Seems no option available for same.
>> Similar question is on pktout_send(), once implementation send the
>> packets out to interface, who keeps responsibility to free them?
>
> Certain APIs, e.g., the APIs for extending / truncating packet head /
> tail, add_data, rem_data, align, etc. may return the same packet
> handle or a replacement packet handle. This is to allow
> implementations flexibility in how the internals of packets are
> managed. Applications need to use the handles returned from these APIs
> rather than trying to cache copies of them across these calls. APIs
> that behave this was state so in their documentation.
>
Ok. But this is all internal to implementation. However , for my
question its about packets exchanged between pktin/pktout and
application.

So for allocation/deallocation,
for input, pktin allocates packets and application free them,
for output, application provide packets and pktout free them after sending.

Is that understanding correct?

Shally

>>
>> Thanks
>> Shally
>>
>>>>
>>>> Could anyone please confirm.
>>>>
>>>> Thanks
>>>> Shally

Re: [lng-odp] API behavior of unsupported mode

[shally verma]

Ok. That clarifies my doubt. Only concern was we shouldn't end up
misusing directive.

Thanks for inputs.
Shally

On Wed, Jul 12, 2017 at 11:16 PM, Bill Fischofer
<bill.fischo...@linaro.org> wrote:
> On Wed, Jul 12, 2017 at 10:33 AM, shally verma
> <shallyvermacav...@gmail.com> wrote:
>> On Wed, Jul 12, 2017 at 8:37 PM, Bill Fischofer
>> <bill.fischo...@linaro.org> wrote:
>>> ODP_UNUSED is useful scaffolding. The alternative is to make a null
>>> reference to unused parameters to avoid compile-time warnings. For
>>> example:
>>>
>>> int odp_xxx(uint32_t x, uint32_t y)
>>> {
>>> (void)y;  /* avoid unused parameter warning for y */
>>>  ...do something useful with x
>>> }
>>>
>>> ODP in general does not support optional APIs, so it would be helpful
>>> to discuss the specific API of concern.
>>
>> API is not optional but behavior is. For example, in capability we
>> indicate whether sync / async mode is supported or not.
>> So, if implementation does not support Async mode (lets say), then API
>> would still be there but non-functional.
>> if user calls odp_comp_compress_enq() then API supposed to fail as it
>> has shown in capability Async is not supported.
>> So, how do we take care of such scenario?
>
> If an application does something that odp_xxx_capability() reports as
> not available then if the application attempts that unsupported call
> results are undefined. Not crashing and instead retuning a failure
> code is certainly preferable in such cases.
>
> In this case the ODP implementation of the unsupported feature would
> behave as you describe. To the extent that this means that there are
> unused parameters in the API call then the implementation can use
> ODP_UNUSED or void casts as described above to avoid compiler warnings
> about unused parameters.
>
>>
>>>Also, do you envision this to be a temporary or permanent restriction?
>>
>> Right now, I added this as temporary fix. But my question is in
>> general for any unsupported feature how an corresponding API should
>> deal with unused params.
>
> Covered above. You can't omit them since they are part of the API
> definition, so you just tell the compiler that their being unused is
> intentional.
>
>>
>> Thanks
>> Shally
>>
>>>
>>> On Wed, Jul 12, 2017 at 7:47 AM, shally verma
>>> <shallyvermacav...@gmail.com> wrote:
>>>> Hi
>>>>
>>>> If any implementation does not support specific mode of operation ,
>>>> say , it only support sync but not async then is it legal to mark
>>>> async API params as ODP_UNUSED? As in such case API may simply return
>>>> with failure code, thus references to params is not actually exercised
>>>> which results in to compile-time errors.
>>>>
>>>> Any suggestions here?
>>>>
>>>> Thanks
>>>> Shally

Re: [lng-odp] Regarding odp_pktin_rcv() packets

[shally verma]

On Wed, Jul 12, 2017 at 8:50 PM, Bill Fischofer
<bill.fischo...@linaro.org> wrote:
> On Wed, Jul 12, 2017 at 7:35 AM, shally verma
> <shallyvermacav...@gmail.com> wrote:
>> I have a question on odp_pktin_recv(odp_pktin_queue_t, odp_packet_t [], int).
>>
>> Once app receives packets associated to the queue, what happens to
>> packets buffers passed to application? Does implementation always
>> assume that packets will be freed by caller and re-allocates fresh
>> packets to queue?
>
> Once an application receives a packet via this or any other call, e.g,
> odp_queue_deq(), odp_schedule(), etc., the application owns the packet
> and must dispose of it either by passing it on to some other entity,
> e.g., via odp_queue_enq(), or else freeing it via odp_packet_free().
> Packet lifecycle management is always explicit so there is no garbage
> collection for "abandoned" packets--those would be memory leaks.
>
>>
>> I referred to packet_io.h spec to understand more on this after
>> pktin_rcv() but didn't get clear information as there seem no
>> handshake mechanism between caller and implementation to indicate that
>> packet buffers are free and can be re-used. So looks like there is
>> implicit assumption that packets are not re-usable after
>> odp_pktin_rcv() call.
>
> A packet is "reused" by either passing it along to some other
> processing element, or else by freeing it back to its pool, from where
> it may be reallocated by someone else.
>Some APIs may consume packets
> and return new versions of them, in which case the free/alloc is done
> by the called API.
>
what do we mean by newer version here? You mean new versions are
returned to pktin? if so, how which API do that?
As for our purpose, we want to avoid free/alloc and rather reuse once
application has used them. Seems no option available for same.
Similar question is on pktout_send(), once implementation send the
packets out to interface, who keeps responsibility to free them?

Thanks
Shally

>>
>> Could anyone please confirm.
>>
>> Thanks
>> Shally

Re: [lng-odp] API behavior of unsupported mode

[shally verma]

On Wed, Jul 12, 2017 at 8:37 PM, Bill Fischofer
<bill.fischo...@linaro.org> wrote:
> ODP_UNUSED is useful scaffolding. The alternative is to make a null
> reference to unused parameters to avoid compile-time warnings. For
> example:
>
> int odp_xxx(uint32_t x, uint32_t y)
> {
> (void)y;  /* avoid unused parameter warning for y */
>  ...do something useful with x
> }
>
> ODP in general does not support optional APIs, so it would be helpful
> to discuss the specific API of concern.

API is not optional but behavior is. For example, in capability we
indicate whether sync / async mode is supported or not.
So, if implementation does not support Async mode (lets say), then API
would still be there but non-functional.
if user calls odp_comp_compress_enq() then API supposed to fail as it
has shown in capability Async is not supported.
So, how do we take care of such scenario?

>Also, do you envision this to be a temporary or permanent restriction?

Right now, I added this as temporary fix. But my question is in
general for any unsupported feature how an corresponding API should
deal with unused params.

Thanks
Shally

>
> On Wed, Jul 12, 2017 at 7:47 AM, shally verma
> <shallyvermacav...@gmail.com> wrote:
>> Hi
>>
>> If any implementation does not support specific mode of operation ,
>> say , it only support sync but not async then is it legal to mark
>> async API params as ODP_UNUSED? As in such case API may simply return
>> with failure code, thus references to params is not actually exercised
>> which results in to compile-time errors.
>>
>> Any suggestions here?
>>
>> Thanks
>> Shally

[lng-odp] API behavior of unsupported mode

[shally verma]

Hi

If any implementation does not support specific mode of operation ,
say , it only support sync but not async then is it legal to mark
async API params as ODP_UNUSED? As in such case API may simply return
with failure code, thus references to params is not actually exercised
which results in to compile-time errors.

Any suggestions here?

Thanks
Shally

[lng-odp] Regarding odp_pktin_rcv() packets

[shally verma]

I have a question on odp_pktin_recv(odp_pktin_queue_t, odp_packet_t [], int).

Once app receives packets associated to the queue, what happens to
packets buffers passed to application? Does implementation always
assume that packets will be freed by caller and re-allocates fresh
packets to queue?

I referred to packet_io.h spec to understand more on this after
pktin_rcv() but didn't get clear information as there seem no
handshake mechanism between caller and implementation to indicate that
packet buffers are free and can be re-used. So looks like there is
implicit assumption that packets are not re-usable after
odp_pktin_rcv() call.

Could anyone please confirm.

Thanks
Shally

[lng-odp] regarding ODP_PKTIO_MACADDR_MAXSIZE in pktio spec

[shally verma]

I have question on definition of this macro  ODP_PKTIO_MACADDR_MAXSIZE
. In pktio,h it is mentioned as " Minimum size of output buffer for
odp_pktio_mac_addr()" where as Macro name is MAXSIZE.

In linux-generic implementation this value is set to 16.

So how to interpret it? Does it mean user need to pass buffer minimum
of this much length ?  i.e. size parameter value in
odp_pktio_mac_addr() >= ODP_PKTIO_MACADDR_MAXSIZE? else API should
fail?

int odp_pktio_mac_addr(odp_pktio_t pktio, void *mac_addr, int size);

Thanks
Shally

Re: [lng-odp] [API-NEXT, PATCH v4 1/1] comp: compression API

[shally verma]

On Tue, Jun 27, 2017 at 2:51 PM, Savolainen, Petri (Nokia - FI/Espoo)
 wrote:
>> > diff --git a/platform/linux-generic/include/odp/api/plat/event_types.h
>> b/platform/linux-generic/include/odp/api/plat/event_types.h
>> > index 0f51783..adf2c31 100644
>> > --- a/platform/linux-generic/include/odp/api/plat/event_types.h
>> > +++ b/platform/linux-generic/include/odp/api/plat/event_types.h
>> > @@ -4,7 +4,6 @@
>> >   * SPDX-License-Identifier: BSD-3-Clause
>> >   */
>> >
>> > -
>> >  /**
>> >   * @file
>> >   *
>> > @@ -39,7 +38,9 @@ typedef enum odp_event_type_t {
>> > ODP_EVENT_PACKET   = 2,
>> > ODP_EVENT_TIMEOUT  = 3,
>> > ODP_EVENT_CRYPTO_COMPL = 4,
>> > -   ODP_EVENT_IPSEC_RESULT = 5
>> > +   ODP_EVENT_IPSEC_RESULT = 5,
>> > +   ODP_EVENT_COMP_COMPL   = 6,
>> > +   ODP_EVENT_DECOMP_COMPL = 7
>> >  } odp_event_type_t;
>
> Event subtypes are now in api-next. This needs to be rebased on top of that. 
> Part of the rebase is definition of results as ODP_EVENT_PACKET type + 
> ODP_EVENT_PACKET_COMP subtype (not as COMP_COMPL events). Only one subtype 
> for comp, the same way as IPsec has ODP_EVENT_PACKET_IPSEC subtype which is 
> for both in- and outbound IPsec. It would be preferable to align comp API to 
> IPsec API also in other parts.

So you mean if application has both compression and decompression
ongoing simultaneously, onus is on application to track whether event
is from compress_enq() or decomp_enq() call ?

Shally
>
> -Petri

Re: [lng-odp] [API-NEXT, PATCH v4 1/1] comp: compression API

[shally verma]

Ping. Reminder to review.

Thanks
Shally

On Tue, Jun 20, 2017 at 5:05 PM, Shally Verma
<shallyvermacav...@gmail.com> wrote:
> API patch to enable compression/decompression support in ODP
>
> Changes from RFC v3:
> Added separate function for compression and decompression.
> Added separate event ODP_EVENT_COMP_COMPL/ODP_EVENT_DECOMP_COMPL for
> compression and decompression completion status in async mode of operation.
>
> Signed-off-by: Shally Verma <sve...@cavium.com>
> Signed-off-by: Mahipal Challa <mcha...@cavium.com>
> ---
>  include/odp/api/spec/comp.h| 810 
> +
>  include/odp/api/spec/event.h   |   3 +-
>  include/odp/arch/arm32-linux/odp/api/abi/comp.h|   7 +
>  include/odp/arch/arm64-linux/odp/api/abi/comp.h|   7 +
>  include/odp/arch/default/api/abi/comp.h|  36 +
>  include/odp/arch/mips64-linux/odp/api/abi/comp.h   |   7 +
>  include/odp/arch/power64-linux/odp/api/abi/comp.h  |   7 +
>  include/odp/arch/x86_32-linux/odp/api/abi/comp.h   |   7 +
>  include/odp/arch/x86_64-linux/odp/api/abi/comp.h   |   7 +
>  platform/linux-generic/include/odp/api/comp.h  |  41 ++
>  .../include/odp/api/plat/comp_types.h  |  44 ++
>  .../include/odp/api/plat/event_types.h |   5 +-
>  platform/linux-generic/include/odp_comp_internal.h |  62 ++
>  .../linux-generic/include/odp_packet_internal.h|   5 +-
>  14 files changed, 1043 insertions(+), 5 deletions(-)
>
> diff --git a/include/odp/api/spec/comp.h b/include/odp/api/spec/comp.h
> new file mode 100644
> index 000..ef11802
> --- /dev/null
> +++ b/include/odp/api/spec/comp.h
> @@ -0,0 +1,810 @@
> +/*
> + */
> +
> +/**
> + * @file
> + *
> + * ODP Compression
> + */
> +
> +#ifndef ODP_API_COMP_H_
> +#define ODP_API_COMP_H_
> +
> +#include 
> +#include 
> +#include 
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +/** @defgroup odp_compression ODP COMP
> + *  ODP Compression defines API set to compress/decompress along with hash
> + *  operations on data. Hash is calculated on plaintext.
> + *
> + *  if opcode = ODP_COMP_COMPRESS, then it will Compress and apply hash,
> + *  if opcode = ODP_COMP_DECOMPRESS, then it will Decompress and apply
> + *  hash.
> + *  Independent hash-only operations are not supported. Implementation should
> + *  perform hash along with valid compression algo.
> + *  Macros, enums, types and operations to utilize compression.
> + *  @{
> + */
> +
> +/**
> + * @def ODP_COMP_SESSION_INVALID
> + * Invalid session handle
> + */
> +
> +/**
> + * @typedef odp_comp_session_t
> + * Compression/Decompression session handle
> + */
> +
> +/**
> + * @typedef odp_comp_compl_t
> +* Compression/Decompression completion event handle
> +*/
> +
> +/**
> + * Compression API operation mode
> + */
> +typedef enum {
> +   /** Synchronous, return results immediately */
> +   ODP_COMP_SYNC,
> +   /** Asynchronous, return results via event queue */
> +   ODP_COMP_ASYNC
> +} odp_comp_op_mode_t;
> +
> +/**
> + * Comp API operation type.
> + *
> + */
> +typedef enum {
> +   /** Compress  */
> +   ODP_COMP_OP_COMPRESS,
> +   /** Decompress */
> +   ODP_COMP_OP_DECOMPRESS
> +} odp_comp_op_t;
> +
> +/**
> + * Comp API hash algorithm
> + *
> + */
> +typedef enum {
> +   /** ODP_COMP_HASH_ALG_NONE*/
> +   ODP_COMP_HASH_ALG_NONE,
> +   /** ODP_COMP_HASH_ALG_SHA1*/
> +   ODP_COMP_HASH_ALG_SHA1,
> +   /**  ODP_COMP_HASH_ALG_SHA256*/
> +   ODP_COMP_HASH_ALG_SHA256
> +} odp_comp_hash_alg_t;
> +
> +/**
> + * Comp API compression algorithm
> + *
> + */
> +typedef enum {
> +   /** No algorithm specified.
> +   * Means no compression, output == input.
> +   * if provided, no operation (compression/decompression or hash)
> +   * applied on input. Added for testing purpose.
> +   */
> +   ODP_COMP_ALG_NULL,
> +   /** DEFLATE - RFC1951 */
> +   ODP_COMP_ALG_DEFLATE,
> +   /** ZLIB - RFC1950 */
> +   ODP_COMP_ALG_ZLIB,
> +   /** LZS */
> +   ODP_COMP_ALG_LZS
> +} odp_comp_alg_t;
> +
> +/**
> + * Comp API session creation return code
> + *
> + */
> +typedef enum {
> +   /** Session created */
> +   ODP_COMP_SES_CREATE_ERR_NONE,
> +   /** Creation failed, no resources */
> +   ODP_COMP_SES_CREATE_ERR_ENOMEM,
> +   /** Creation failed, bad compression params */
> +   ODP_COMP_SES_CREATE_ERR_INV_COMP,
> +   /** Creation failed, bad hash params */

Re: [lng-odp] Need to standardize tools version

[shally verma]

On Thu, Jun 22, 2017 at 3:03 AM, Honnappa Nagarahalli
 wrote:
> Why is it Hard? It is a matter of documenting/advertising which
> versions we are using in CI and making that as a minimum standard. If
> someone has a different compiler they can always submit the patches
> for their compilers.
>
I second this opinion as I also had same question in last weekly public call.
if using a travis CI a way to go then it will be helpful if could be
documented as minimum acceptance criteria for patches with bit of
pointers on how to use it to help novice user like me.

Thanks
Shally


> On 21 June 2017 at 14:49, Maxim Uvarov  wrote:
>> it's very hard to standardize tools and compiler version. For now to
>> validate patches we use Linaro CI (odp-check scripts) and Travis CI
>> which is based on some stable ubuntu version. Also we really want
>> that all people can download odp, compile it and run. It's very rare
>> case if different tools introduce issues but some times it happen.
>> If such issue is found before patch submission it has to be fixed before.
>>
>> Maxim.
>>
>> On 06/21/17 22:19, Bill Fischofer wrote:
>>> On Wed, Jun 21, 2017 at 1:30 PM, Honnappa Nagarahalli
>>>  wrote:
 On 21 June 2017 at 12:23, Bill Fischofer  wrote:
> ODP is fairly open-ended in this regard because in theory we're only
> dependent on
>
> - A C99-conforming compiler
> - A platform that supports a reasonably recent Linux kernel
>
> Today we do test on 32 and 64 bit systems, and try to support both GCC
> and clang, however as newer versions of these tools get released we
> sometimes encounter problems. The same is true with older releases. We
> try to accommodate, especially when the fix to support a wider range
> of tools and platforms is relatively straightforward.
>
> It's not possible to test exhaustively on every possible combination
> so when problems occur we open and fix bugs. However, once we fix a
> bug we prefer to fix it only once, which means that in-flight patches
> should be checked to see if they have a similar problem and should be
> revised to avoid that problem as well. That way we don't fix the same
> problem multiple times.
>
 Agree. For anyone to submit a patch, they need to have a reference of
 what needs to be done. Scalable scheduler is an example, where we have
 been discovering at every patch that there is a new thing that needs
 to be done to accept the patch. If it was known upfront, we can work
 on them from day 1. This sets up the expectation and saves time for
 everyone, knowing that the patch works for this minimum acceptance
 criteria. For ex: I do not know how many times you have tried to
 compile the code and discovered that it does not compile. I would like
 to avoid those problems.
>>>
>>> That's what we're trying to do with CI and Travis. In this specific
>>> case Petri discovered an issue that effected an older LTS level of
>>> Ubuntu and provided a simple fix to the issue. So I don't see a
>>> problem with propagating that fix as Brian seems to have confirmed
>>> that the fix is good.
>>>

>
> On Wed, Jun 21, 2017 at 11:58 AM, Honnappa Nagarahalli
>  wrote:
>> Along with this, we need to standardize 32b/64b compilations and the
>> platforms on which we run the test cases.
>> Thanks,
>> Honnappa
>>
>> On 21 June 2017 at 11:38, Honnappa Nagarahalli
>>  wrote:
>>> Hi,
>>>I think there is a need to identify tools and specific versions of
>>> the tools from patch acceptance perspective. Any failures outside of
>>> these versions should be the responsibility of the person facing the
>>> issues, they should submit a patch for those versions and tools.
>>>
>>> Travis CI is a step in that direction. But I think we still allow
>>> submissions of patches via email. So, for this case, should we
>>> standardize the tools and versions being used in Travis CI as the
>>> acceptance criteria?
>>>
>>> Thanks,
>>> Honnappa
>>

[lng-odp] [API-NEXT, PATCH v4 1/1] comp: compression API

[Shally Verma]

API patch to enable compression/decompression support in ODP

Changes from RFC v3:
Added separate function for compression and decompression.
Added separate event ODP_EVENT_COMP_COMPL/ODP_EVENT_DECOMP_COMPL for
compression and decompression completion status in async mode of operation.

Signed-off-by: Shally Verma <sve...@cavium.com>
Signed-off-by: Mahipal Challa <mcha...@cavium.com>
---
 include/odp/api/spec/comp.h| 810 +
 include/odp/api/spec/event.h   |   3 +-
 include/odp/arch/arm32-linux/odp/api/abi/comp.h|   7 +
 include/odp/arch/arm64-linux/odp/api/abi/comp.h|   7 +
 include/odp/arch/default/api/abi/comp.h|  36 +
 include/odp/arch/mips64-linux/odp/api/abi/comp.h   |   7 +
 include/odp/arch/power64-linux/odp/api/abi/comp.h  |   7 +
 include/odp/arch/x86_32-linux/odp/api/abi/comp.h   |   7 +
 include/odp/arch/x86_64-linux/odp/api/abi/comp.h   |   7 +
 platform/linux-generic/include/odp/api/comp.h  |  41 ++
 .../include/odp/api/plat/comp_types.h  |  44 ++
 .../include/odp/api/plat/event_types.h |   5 +-
 platform/linux-generic/include/odp_comp_internal.h |  62 ++
 .../linux-generic/include/odp_packet_internal.h|   5 +-
 14 files changed, 1043 insertions(+), 5 deletions(-)

diff --git a/include/odp/api/spec/comp.h b/include/odp/api/spec/comp.h
new file mode 100644
index 000..ef11802
--- /dev/null
+++ b/include/odp/api/spec/comp.h
@@ -0,0 +1,810 @@
+/*
+ */
+
+/**
+ * @file
+ *
+ * ODP Compression
+ */
+
+#ifndef ODP_API_COMP_H_
+#define ODP_API_COMP_H_
+
+#include 
+#include 
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/** @defgroup odp_compression ODP COMP
+ *  ODP Compression defines API set to compress/decompress along with hash
+ *  operations on data. Hash is calculated on plaintext.
+ *
+ *  if opcode = ODP_COMP_COMPRESS, then it will Compress and apply hash,
+ *  if opcode = ODP_COMP_DECOMPRESS, then it will Decompress and apply
+ *  hash.
+ *  Independent hash-only operations are not supported. Implementation should
+ *  perform hash along with valid compression algo.
+ *  Macros, enums, types and operations to utilize compression.
+ *  @{
+ */
+
+/**
+ * @def ODP_COMP_SESSION_INVALID
+ * Invalid session handle
+ */
+
+/**
+ * @typedef odp_comp_session_t
+ * Compression/Decompression session handle
+ */
+
+/**
+ * @typedef odp_comp_compl_t
+* Compression/Decompression completion event handle
+*/
+
+/**
+ * Compression API operation mode
+ */
+typedef enum {
+   /** Synchronous, return results immediately */
+   ODP_COMP_SYNC,
+   /** Asynchronous, return results via event queue */
+   ODP_COMP_ASYNC
+} odp_comp_op_mode_t;
+
+/**
+ * Comp API operation type.
+ *
+ */
+typedef enum {
+   /** Compress  */
+   ODP_COMP_OP_COMPRESS,
+   /** Decompress */
+   ODP_COMP_OP_DECOMPRESS
+} odp_comp_op_t;
+
+/**
+ * Comp API hash algorithm
+ *
+ */
+typedef enum {
+   /** ODP_COMP_HASH_ALG_NONE*/
+   ODP_COMP_HASH_ALG_NONE,
+   /** ODP_COMP_HASH_ALG_SHA1*/
+   ODP_COMP_HASH_ALG_SHA1,
+   /**  ODP_COMP_HASH_ALG_SHA256*/
+   ODP_COMP_HASH_ALG_SHA256
+} odp_comp_hash_alg_t;
+
+/**
+ * Comp API compression algorithm
+ *
+ */
+typedef enum {
+   /** No algorithm specified.
+   * Means no compression, output == input.
+   * if provided, no operation (compression/decompression or hash)
+   * applied on input. Added for testing purpose.
+   */
+   ODP_COMP_ALG_NULL,
+   /** DEFLATE - RFC1951 */
+   ODP_COMP_ALG_DEFLATE,
+   /** ZLIB - RFC1950 */
+   ODP_COMP_ALG_ZLIB,
+   /** LZS */
+   ODP_COMP_ALG_LZS
+} odp_comp_alg_t;
+
+/**
+ * Comp API session creation return code
+ *
+ */
+typedef enum {
+   /** Session created */
+   ODP_COMP_SES_CREATE_ERR_NONE,
+   /** Creation failed, no resources */
+   ODP_COMP_SES_CREATE_ERR_ENOMEM,
+   /** Creation failed, bad compression params */
+   ODP_COMP_SES_CREATE_ERR_INV_COMP,
+   /** Creation failed, bad hash params */
+   ODP_COMP_SES_CREATE_ERR_INV_HASH,
+   /** Creation failed,requested configuration not supported*/
+   ODP_COMP_SES_CREATE_ERR_NOT_SUPPORTED
+} odp_comp_ses_create_err_t;
+
+/**
+ * Comp API operation return codes
+ *
+ */
+typedef enum {
+   /** Operation completed successfully*/
+   ODP_COMP_ERR_NONE,
+   /** Invalid user data pointers*/
+   ODP_COMP_ERR_DATA_PTR,
+   /** Invalid input data size*/
+   ODP_COMP_ERR_DATA_SIZE,
+   /**  Compression and/or hash Algo failure*/
+   ODP_COMP_ERR_ALGO_FAIL,
+   /** Operation paused due to insufficient output buffer.
+   *
+   * This is not an error condition. On seeing this situation,
+   * Implementation should maintain context of in-progress operation and
+   * application should call packet processing API again with valid
+   * output buffer but no other a

[lng-odp] [API-NEXT, PATCH v4 0/1] comp: compression API

[Shally Verma]

Shally Verma (1):
  comp: compression API

  Changes from RFC v3:
Add separate function for compresion/decompression
Add separate events ODP_EVENT_COMP_COMPL for compression and 
ODP_EVENT_DECOMP_COMPL decompression completion notification.

 include/odp/api/spec/comp.h| 810 +
 include/odp/api/spec/event.h   |   3 +-
 include/odp/arch/arm32-linux/odp/api/abi/comp.h|   7 +
 include/odp/arch/arm64-linux/odp/api/abi/comp.h|   7 +
 include/odp/arch/default/api/abi/comp.h|  36 +
 include/odp/arch/mips64-linux/odp/api/abi/comp.h   |   7 +
 include/odp/arch/power64-linux/odp/api/abi/comp.h  |   7 +
 include/odp/arch/x86_32-linux/odp/api/abi/comp.h   |   7 +
 include/odp/arch/x86_64-linux/odp/api/abi/comp.h   |   7 +
 platform/linux-generic/include/odp/api/comp.h  |  41 ++
 .../include/odp/api/plat/comp_types.h  |  44 ++
 .../include/odp/api/plat/event_types.h |   5 +-
 platform/linux-generic/include/odp_comp_internal.h |  62 ++
 .../linux-generic/include/odp_packet_internal.h|   5 +-
 14 files changed, 1043 insertions(+), 5 deletions(-)
 create mode 100644 include/odp/api/spec/comp.h
 create mode 100644 include/odp/arch/arm32-linux/odp/api/abi/comp.h
 create mode 100644 include/odp/arch/arm64-linux/odp/api/abi/comp.h
 create mode 100644 include/odp/arch/default/api/abi/comp.h
 create mode 100644 include/odp/arch/mips64-linux/odp/api/abi/comp.h
 create mode 100644 include/odp/arch/power64-linux/odp/api/abi/comp.h
 create mode 100644 include/odp/arch/x86_32-linux/odp/api/abi/comp.h
 create mode 100644 include/odp/arch/x86_64-linux/odp/api/abi/comp.h
 create mode 100644 platform/linux-generic/include/odp/api/comp.h
 create mode 100644 platform/linux-generic/include/odp/api/plat/comp_types.h
 create mode 100644 platform/linux-generic/include/odp_comp_internal.h

-- 
1.9.1

Re: [lng-odp] [API-NEXT PATCH v3 1/3] api: event: add subtype to expand event type

[shally verma]

On Tue, Jun 20, 2017 at 3:12 PM, Savolainen, Petri (Nokia - FI/Espoo)
<petri.savolai...@nokia.com> wrote:
>
>
>> -Original Message-----
>> From: shally verma [mailto:shallyvermacav...@gmail.com]
>> Sent: Tuesday, June 20, 2017 8:55 AM
>> To: Bill Fischofer <bill.fischo...@linaro.org>
>> Cc: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia.com>;
>> lng-odp-forward <lng-odp@lists.linaro.org>
>> Subject: Re: [lng-odp] [API-NEXT PATCH v3 1/3] api: event: add subtype to
>> expand event type
>>
>> On Fri, Jun 16, 2017 at 7:15 PM, Bill Fischofer
>> <bill.fischo...@linaro.org> wrote:
>> > On Fri, Jun 16, 2017 at 8:33 AM, shally verma
>> > <shallyvermacav...@gmail.com> wrote:
>> >> On Fri, Jun 16, 2017 at 6:42 PM, Bill Fischofer
>> >> <bill.fischo...@linaro.org> wrote:
>> >>> On Fri, Jun 16, 2017 at 8:04 AM, Savolainen, Petri (Nokia - FI/Espoo)
>> >>> <petri.savolai...@nokia.com> wrote:
>> >>>>> > diff --git a/include/odp/api/spec/event.h
>> b/include/odp/api/spec/event.h
>> >>>>> > index f22efce5..2ad3ce84 100644
>> >>>>> > --- a/include/odp/api/spec/event.h
>> >>>>> > +++ b/include/odp/api/spec/event.h
>> >>>>> > @@ -37,21 +37,91 @@ extern "C" {
>> >>>>> >
>> >>>>> >  /**
>> >>>>> >   * @typedef odp_event_type_t
>> >>>>> > - * ODP event types:
>> >>>>> > - * ODP_EVENT_BUFFER, ODP_EVENT_PACKET, ODP_EVENT_TIMEOUT,
>> >>>>> > - * ODP_EVENT_CRYPTO_COMPL, ODP_EVENT_IPSEC_RESULT,
>> >>>>> ODP_EVENT_IPSEC_STATUS
>> >>>>> > + * Event type
>> >>>>> > + *
>> >>>>> > + * Event type specifies purpose and general format of an event.
>> It can
>> >>>>> be
>> >>>>> > + * checked with odp_event_type() or odp_event_types(). Each event
>> type
>> >>>>> has
>> >>>>> > + * functions (e.g. odp_buffer_from_event()) to convert between
>> the
>> >>>>> generic event
>> >>>>> > + * handle (odp_event_t) and the type specific handle (e.g.
>> >>>>> odp_buffer_t).
>> >>>>> > + * Results are undefined, if conversion function of a wrong event
>> type
>> >>>>> is used.
>> >>>>> > + * Application cannot change event type by chaining conversion
>> >>>>> functions.
>> >>>>> > + *
>> >>>>> > + * List of event types:
>> >>>>> > + * - ODP_EVENT_BUFFER
>> >>>>> > + * - Buffer event (odp_buffer_t) for simple data storage and
>> >>>>> message passing
>> >>>>> > + * - ODP_EVENT_PACKET
>> >>>>> > + * - Packet event (odp_packet_t) containing packet data and
>> plenty
>> >>>>> of
>> >>>>>
>> >>>>> Why "plenty of"? "containing packet data and associated metadata"
>> >>>>> seems sufficient.
>> >>>>
>> >>>> It highlights that packets should be used only for packets, not as
>> random buffer space (buffers are simple vs. packets are complex).
>> >>>
>> >>> Ok, it just looked a bit odd. Not a biggie.
>> >>>
>> >>>>
>> >>>> BTW. It would have been nice to get all review comments in one go. I
>> did sent v3 as there were no more comments. I cannot do v4 before our lab
>> is back online from a maintenance break... Hopefully v4 is not necessary.
>> >>>
>> >>> Still working on it. This series needs Bala and Nikhil's reviews as a
>> >>> check against their HW. But so far this looks very reasonable.
>> >>>
>> >>>>
>> >>>> -Petri
>> >>
>> >> So, how does this affect event notification mechanism now?
>> >> Currently we had ODP_EVENT_COMP_COMPL set on a packet to mark
>> >> compression/decompression complete status on requested input. So that
>> >> still remain valid Or we need to introduce it like:
>> >>
>> >> event ODP_EVENT_PACKET
>> >> subtype ODP_EVENT_PACKET_COMP_COMPL?
>> >
>> > For consistency with the subtype patt

Re: [lng-odp] [API-NEXT PATCH v3 1/3] api: event: add subtype to expand event type

[shally verma]

On Fri, Jun 16, 2017 at 7:15 PM, Bill Fischofer
<bill.fischo...@linaro.org> wrote:
> On Fri, Jun 16, 2017 at 8:33 AM, shally verma
> <shallyvermacav...@gmail.com> wrote:
>> On Fri, Jun 16, 2017 at 6:42 PM, Bill Fischofer
>> <bill.fischo...@linaro.org> wrote:
>>> On Fri, Jun 16, 2017 at 8:04 AM, Savolainen, Petri (Nokia - FI/Espoo)
>>> <petri.savolai...@nokia.com> wrote:
>>>>> > diff --git a/include/odp/api/spec/event.h b/include/odp/api/spec/event.h
>>>>> > index f22efce5..2ad3ce84 100644
>>>>> > --- a/include/odp/api/spec/event.h
>>>>> > +++ b/include/odp/api/spec/event.h
>>>>> > @@ -37,21 +37,91 @@ extern "C" {
>>>>> >
>>>>> >  /**
>>>>> >   * @typedef odp_event_type_t
>>>>> > - * ODP event types:
>>>>> > - * ODP_EVENT_BUFFER, ODP_EVENT_PACKET, ODP_EVENT_TIMEOUT,
>>>>> > - * ODP_EVENT_CRYPTO_COMPL, ODP_EVENT_IPSEC_RESULT,
>>>>> ODP_EVENT_IPSEC_STATUS
>>>>> > + * Event type
>>>>> > + *
>>>>> > + * Event type specifies purpose and general format of an event. It can
>>>>> be
>>>>> > + * checked with odp_event_type() or odp_event_types(). Each event type
>>>>> has
>>>>> > + * functions (e.g. odp_buffer_from_event()) to convert between the
>>>>> generic event
>>>>> > + * handle (odp_event_t) and the type specific handle (e.g.
>>>>> odp_buffer_t).
>>>>> > + * Results are undefined, if conversion function of a wrong event type
>>>>> is used.
>>>>> > + * Application cannot change event type by chaining conversion
>>>>> functions.
>>>>> > + *
>>>>> > + * List of event types:
>>>>> > + * - ODP_EVENT_BUFFER
>>>>> > + * - Buffer event (odp_buffer_t) for simple data storage and
>>>>> message passing
>>>>> > + * - ODP_EVENT_PACKET
>>>>> > + * - Packet event (odp_packet_t) containing packet data and plenty
>>>>> of
>>>>>
>>>>> Why "plenty of"? "containing packet data and associated metadata"
>>>>> seems sufficient.
>>>>
>>>> It highlights that packets should be used only for packets, not as random 
>>>> buffer space (buffers are simple vs. packets are complex).
>>>
>>> Ok, it just looked a bit odd. Not a biggie.
>>>
>>>>
>>>> BTW. It would have been nice to get all review comments in one go. I did 
>>>> sent v3 as there were no more comments. I cannot do v4 before our lab is 
>>>> back online from a maintenance break... Hopefully v4 is not necessary.
>>>
>>> Still working on it. This series needs Bala and Nikhil's reviews as a
>>> check against their HW. But so far this looks very reasonable.
>>>
>>>>
>>>> -Petri
>>
>> So, how does this affect event notification mechanism now?
>> Currently we had ODP_EVENT_COMP_COMPL set on a packet to mark
>> compression/decompression complete status on requested input. So that
>> still remain valid Or we need to introduce it like:
>>
>> event ODP_EVENT_PACKET
>> subtype ODP_EVENT_PACKET_COMP_COMPL?
>
> For consistency with the subtype pattern defined here I'd guess
> ODP_EVENT_PACKET_COMP would be the name to use.
>
>>
Ok. but it still leave question open for me. Should existing
Compression/Crypto completion event is going to be there or do we need
to change as per current proposal? Or current proposal is for newer
event notifications. When an compression/encryption event should be
considered as sub-event to packet? What event should be if user send a
buffer for compression/decompression than packet? May be I am missing
broader perspective to this proposal.

Also, I have bit of confusion with event type enums placement.
ODO_EVENT_PACKET/ODP_EVENT_CRYPTO_COMPL .. are these standard event
types and public? Because I see their definition inside
platform/linux-generic/include/odp/api/plat/event_types.h instead of
standard spec file at include/odp/api/spec/event.h giving me an
impression they are platform specific enum defines.

So far I was under impression because they are platform specific so we
are introducing conversion APIs like
odp_xxx_event_from_event() so that user don't need to know specific
event enumeration. As example (referring to crypto as base design) ,
we have:

odp_comp_compl_t odp_comp_compl_from_event(odp_event_t);
odp_comp_compl_result(odp_comp_compl_t comp_handle,
odp_comp_op_result_t *result);

Am I missing any base assumption here?

>> Thanks
>> Shally

Re: [lng-odp] [API-NEXT PATCH v3 1/3] api: event: add subtype to expand event type

[shally verma]

On Fri, Jun 16, 2017 at 6:42 PM, Bill Fischofer
 wrote:
> On Fri, Jun 16, 2017 at 8:04 AM, Savolainen, Petri (Nokia - FI/Espoo)
>  wrote:
>>> > diff --git a/include/odp/api/spec/event.h b/include/odp/api/spec/event.h
>>> > index f22efce5..2ad3ce84 100644
>>> > --- a/include/odp/api/spec/event.h
>>> > +++ b/include/odp/api/spec/event.h
>>> > @@ -37,21 +37,91 @@ extern "C" {
>>> >
>>> >  /**
>>> >   * @typedef odp_event_type_t
>>> > - * ODP event types:
>>> > - * ODP_EVENT_BUFFER, ODP_EVENT_PACKET, ODP_EVENT_TIMEOUT,
>>> > - * ODP_EVENT_CRYPTO_COMPL, ODP_EVENT_IPSEC_RESULT,
>>> ODP_EVENT_IPSEC_STATUS
>>> > + * Event type
>>> > + *
>>> > + * Event type specifies purpose and general format of an event. It can
>>> be
>>> > + * checked with odp_event_type() or odp_event_types(). Each event type
>>> has
>>> > + * functions (e.g. odp_buffer_from_event()) to convert between the
>>> generic event
>>> > + * handle (odp_event_t) and the type specific handle (e.g.
>>> odp_buffer_t).
>>> > + * Results are undefined, if conversion function of a wrong event type
>>> is used.
>>> > + * Application cannot change event type by chaining conversion
>>> functions.
>>> > + *
>>> > + * List of event types:
>>> > + * - ODP_EVENT_BUFFER
>>> > + * - Buffer event (odp_buffer_t) for simple data storage and
>>> message passing
>>> > + * - ODP_EVENT_PACKET
>>> > + * - Packet event (odp_packet_t) containing packet data and plenty
>>> of
>>>
>>> Why "plenty of"? "containing packet data and associated metadata"
>>> seems sufficient.
>>
>> It highlights that packets should be used only for packets, not as random 
>> buffer space (buffers are simple vs. packets are complex).
>
> Ok, it just looked a bit odd. Not a biggie.
>
>>
>> BTW. It would have been nice to get all review comments in one go. I did 
>> sent v3 as there were no more comments. I cannot do v4 before our lab is 
>> back online from a maintenance break... Hopefully v4 is not necessary.
>
> Still working on it. This series needs Bala and Nikhil's reviews as a
> check against their HW. But so far this looks very reasonable.
>
>>
>> -Petri

So, how does this affect event notification mechanism now?
Currently we had ODP_EVENT_COMP_COMPL set on a packet to mark
compression/decompression complete status on requested input. So that
still remain valid Or we need to introduce it like:

event ODP_EVENT_PACKET
subtype ODP_EVENT_PACKET_COMP_COMPL?

Thanks
Shally

Re: [lng-odp] [PATCH v4 0/2] GCC 7 fixes

[shally verma]

Does it mean that going further there would be certain limitation on
gcc version to be used? I just tried to compile next branch and
./configure throws an error

./configure: line 22786: syntax error near unexpected token
`-Wimplicit-fallthrough=0,'
./configure: line 22786: `AX_CHECK_COMPILE_FLAG(-Wimplicit-fallthrough=0,'

I'm using gcc 4.8.4

Shally

On Thu, Jun 8, 2017 at 9:41 AM, Bill Fischofer
 wrote:
> For the v4 series:
>
> Reviewed-and-tested-by: Bill Fischofer 
>
> On Wed, Jun 7, 2017 at 10:40 PM, Brian Brooks  wrote:
>> The GCC 7 series introduces changes that expose ODP compilation
>> issues. These include case statement fall through warnings, and
>> stricter checks on potential string overflows and other semantic
>> analysis.
>>
>> Fixes: https://bugs.linaro.org/show_bug.cgi?id=3027
>>
>> Brian Brooks (2):
>>   build: GCC 7 fixes
>>   pktio: GCC 7 fixes
>>
>>  DEPENDENCIES  |  5 +--
>>  configure.ac  | 13 
>>  platform/linux-generic/m4/configure.m4| 44 
>> +++
>>  test/common_plat/validation/api/pktio/pktio.c |  4 ++-
>>  4 files changed, 63 insertions(+), 3 deletions(-)
>>
>> --
>>
>> v4:
>>  - Add -Werror to AX_CHECK_COMPILE_FLAG for Clang (Bill)
>>
>> v3:
>>  - Split into multiple patches files (Maxim)
>>  - Disable warnings in favor of patching right now (Dmitry)
>>  - Improve libatomic detection in autoconf (Dmitry)
>>  - Add autoconf-arch to DEPENDENCIES file
>>
>> v2:
>>  - Add Bug id to commit message (Bill)
>>
>> 2.13.0
>>

Re: [lng-odp] [RFC, API-NEXT v3 1/1] comp: compression interface

[shally verma]

Do we have any more comments on same?

Petri

Could you get time to review feedback?

Can we consider v3 as accepted?

Thanks
Shally

On Thu, Jun 1, 2017 at 10:05 PM, shally verma
<shallyvermacav...@gmail.com> wrote:
> Re-sending with updated comments.
>
> Regards
> Shally
>
> On Thu, Jun 1, 2017 at 7:58 PM, Verma, Shally <shally.ve...@cavium.com>
> wrote:
>>
>> Regards
>> Shally
>>
>> -Original Message-
>> From: Savolainen, Petri (Nokia - FI/Espoo)
>> [mailto:petri.savolai...@nokia.com]
>> Sent: 01 June 2017 18:20
>> To: Shally Verma <shallyvermacav...@gmail.com>; lng-odp@lists.linaro.org
>> Cc: Challa, Mahipal <mahipal.cha...@cavium.com>; Narayana, Prasad Athreya
>> <prasadathreya.naray...@cavium.com>; Verma, Shally <shally.ve...@cavium.com>
>> Subject: RE: [lng-odp] [RFC, API-NEXT v3 1/1] comp: compression interface
>>
>>
>>
>> > -Original Message-
>> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
>> > Shally Verma
>> > Sent: Monday, May 22, 2017 9:55 AM
>> > To: lng-odp@lists.linaro.org
>> > Cc: Mahipal Challa <mcha...@cavium.com>; pathr...@cavium.com; Shally
>> > Verma <sve...@cavium.com>
>> > Subject: [lng-odp] [RFC, API-NEXT v3 1/1] comp: compression interface
>> >
>>
>> A short description (5-10 lines) about the new API should be added here.
>>
>> For example: what kind of compression this API offers. How it's used.
>> Which kind of applications typical use it.
>>
>> Current ODP Comp interface is designed to support widely used lossless
>> data compression schemes : deflate, zlib and lzs.
>> Typical applications include (but not limited to ) IPComp, other
>> application and transport layer protocols such as HTTP compression.
>>
>> Changes from V2:
>> Add separate API for sync and async operation,
>> Add separate API to load dictionary,
>> Removed SHA only support from compression interface,
>> Rename SHA operations as hash operation.
>> Add reference odp_packet_data_range_t for accessing packet buffer
>>
>>
>> > Signed-off-by: Shally Verma <sve...@cavium.com>
>> > Signed-off-by: Mahipal Challa <mcha...@cavium.com>
>> > ---
>> >  include/odp/api/spec/comp.h | 740
>> > 
>> >  1 file changed, 740 insertions(+)
>> >
>> > diff --git a/include/odp/api/spec/comp.h b/include/odp/api/spec/comp.h
>> > new file mode 100644 index 000..6c13ad4
>> > --- /dev/null
>> > +++ b/include/odp/api/spec/comp.h
>> > @@ -0,0 +1,740 @@
>> > +/*
>> > + */
>> > +
>> > +/**
>> > + * @file
>> > + *
>> > + * ODP Compression
>> > + */
>> > +
>> > +#ifndef ODP_API_COMP_H_
>> > +#define ODP_API_COMP_H_
>> > +
>> > +#include 
>> > +#include 
>> > +#include 
>> > +
>> > +#ifdef __cplusplus
>> > +extern "C" {
>> > +#endif
>> > +
>> > +/** @defgroup odp_compression ODP COMP
>> > + *  ODP Compression defines interface to compress/decompress along
>> > +with
>> > hash
>> > + *  operations.
>> > + *
>> > + *  Compression here implicitly refer to both compression and
>> > decompression.
>>
>> Typo: implicitly.
>>
>> Actually, you could just say: "Compression API supports both compression
>> and decompression operations."
>>
>>
>> > + *  Example, compression algo 'deflate' mean both 'deflate' and
>> > 'inflate'.
>> > + *
>> > + *  if opcode = ODP_COMP_COMPRESS, then it will Compress and/or apply
>> > hash,
>> > + *  if opcode = ODP_COMP_DECOMPRESS, then it will Decompress and/or
>> > + apply
>> > + *  hash.
>>
>> I think it would be better to have separate operations for compress and
>> decompress. Application would typically call one on ingress side and the
>> other on egress side, or maybe only one of those. Dual functionality would
>> make sense if every second packet on the same code path would be compressed
>> and every second decompressed, but I think that's not the case.
>>
>> Application will create either Compression session or Decompression
>> session. so if two operations are requested simultaneously, then two
>> sessions would be created where each session will have its specific
>> operation context. So 

Re: [lng-odp] [RFC, API-NEXT v3 1/1] comp: compression interface

[shally verma]

Re-sending with updated comments.

Regards
Shally

On Thu, Jun 1, 2017 at 7:58 PM, Verma, Shally <shally.ve...@cavium.com>
wrote:

> Regards
> Shally
>
> -Original Message-
> From: Savolainen, Petri (Nokia - FI/Espoo) [mailto:petri.savolainen@
> nokia.com]
> Sent: 01 June 2017 18:20
> To: Shally Verma <shallyvermacav...@gmail.com>; lng-odp@lists.linaro.org
> Cc: Challa, Mahipal <mahipal.cha...@cavium.com>; Narayana, Prasad Athreya
> <prasadathreya.naray...@cavium.com>; Verma, Shally <
> shally.ve...@cavium.com>
> Subject: RE: [lng-odp] [RFC, API-NEXT v3 1/1] comp: compression interface
>
>
>
> > -Original Message-----
> > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
> > Shally Verma
> > Sent: Monday, May 22, 2017 9:55 AM
> > To: lng-odp@lists.linaro.org
> > Cc: Mahipal Challa <mcha...@cavium.com>; pathr...@cavium.com; Shally
> > Verma <sve...@cavium.com>
> > Subject: [lng-odp] [RFC, API-NEXT v3 1/1] comp: compression interface
> >
>
> A short description (5-10 lines) about the new API should be added here.
>
> For example: what kind of compression this API offers. How it's used.
> Which kind of applications typical use it.
>
> Current ODP Comp interface is designed to support widely used lossless
> data compression schemes : deflate, zlib and lzs.
> Typical applications include (but not limited to ) IPComp, other
> application and transport layer protocols such as HTTP compression.
>
> Changes from V2:
> Add separate API for sync and async operation,
> Add separate API to load dictionary,
> Removed SHA only support from compression interface,
> Rename SHA operations as hash operation.
> Add reference odp_packet_data_range_t for accessing packet buffer
>
>
> > Signed-off-by: Shally Verma <sve...@cavium.com>
> > Signed-off-by: Mahipal Challa <mcha...@cavium.com>
> > ---
> >  include/odp/api/spec/comp.h | 740
> > 
> >  1 file changed, 740 insertions(+)
> >
> > diff --git a/include/odp/api/spec/comp.h b/include/odp/api/spec/comp.h
> > new file mode 100644 index 000..6c13ad4
> > --- /dev/null
> > +++ b/include/odp/api/spec/comp.h
> > @@ -0,0 +1,740 @@
> > +/*
> > + */
> > +
> > +/**
> > + * @file
> > + *
> > + * ODP Compression
> > + */
> > +
> > +#ifndef ODP_API_COMP_H_
> > +#define ODP_API_COMP_H_
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#ifdef __cplusplus
> > +extern "C" {
> > +#endif
> > +
> > +/** @defgroup odp_compression ODP COMP
> > + *  ODP Compression defines interface to compress/decompress along
> > +with
> > hash
> > + *  operations.
> > + *
> > + *  Compression here implicitly refer to both compression and
> > decompression.
>
> Typo: implicitly.
>
> Actually, you could just say: "Compression API supports both compression
> and decompression operations."
>
>
> > + *  Example, compression algo 'deflate' mean both 'deflate' and
> > 'inflate'.
> > + *
> > + *  if opcode = ODP_COMP_COMPRESS, then it will Compress and/or apply
> > hash,
> > + *  if opcode = ODP_COMP_DECOMPRESS, then it will Decompress and/or
> > + apply
> > + *  hash.
>
> I think it would be better to have separate operations for compress and
> decompress. Application would typically call one on ingress side and the
> other on egress side, or maybe only one of those. Dual functionality would
> make sense if every second packet on the same code path would be compressed
> and every second decompressed, but I think that's not the case.
>
> Application will create either Compression session or Decompression
> session. so if two operations are requested simultaneously, then two
> sessions would be created where each session will have its specific
> operation context. So this way Compress and Decompress will be two separate
> operations.
>


> > + *
> > + *  Current version of interface allow Compression ONLY,and
> > + *  both Compression + hash ONLY sessions.
>
> What this comment tries to say. Decompression is not supported at all ? Or
>
- Decompression and Decompression+hash supported

"hashing only" is not supported yet.
>
-Yes "hashing only" not supported.

"Hashing only" should not be a target for this API.
> - Yes. it is not.
>


>
>
> > + *
> > + *  Macros, enums, types and operations to utilise compression.
> > + *  @{
> > + */
> > +
> > +/**
> &g

Re: [lng-odp] [RFC, API-NEXT v3 1/1] comp: compression interface

[shally verma]

Reminder.
Could we please have acceptance criteria on same.

Thanks
Shally

On Mon, May 22, 2017 at 12:24 PM, Shally Verma <shallyvermacav...@gmail.com>
wrote:

> Signed-off-by: Shally Verma <sve...@cavium.com>
> Signed-off-by: Mahipal Challa <mcha...@cavium.com>
> ---
>  include/odp/api/spec/comp.h | 740 ++
> ++
>  1 file changed, 740 insertions(+)
>
> diff --git a/include/odp/api/spec/comp.h b/include/odp/api/spec/comp.h
> new file mode 100644
> index 000..6c13ad4
> --- /dev/null
> +++ b/include/odp/api/spec/comp.h
> @@ -0,0 +1,740 @@
> +/*
> + */
> +
> +/**
> + * @file
> + *
> + * ODP Compression
> + */
> +
> +#ifndef ODP_API_COMP_H_
> +#define ODP_API_COMP_H_
> +
> +#include 
> +#include 
> +#include 
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +/** @defgroup odp_compression ODP COMP
> + *  ODP Compression defines interface to compress/decompress along with
> hash
> + *  operations.
> + *
> + *  Compression here implicilty refer to both compression and
> decompression.
> + *  Example, compression algo 'deflate' mean both 'deflate' and 'inflate'.
> + *
> + *  if opcode = ODP_COMP_COMPRESS, then it will Compress and/or apply
> hash,
> + *  if opcode = ODP_COMP_DECOMPRESS, then it will Decompress and/or apply
> + *  hash.
> + *
> + *  Current version of interface allow Compression ONLY,and
> + *  both Compression + hash ONLY sessions.
> + *
> + *  Macros, enums, types and operations to utilise compression.
> + *  @{
> + */
> +
> +/**
> + * @def ODP_COMP_SESSION_INVALID
> + * Invalid session handle
> + */
> +
> +/**
> + * @typedef odp_comp_session_t (platform dependent)
> + * Comp API opaque session handle
> + */
> +
> +/**
> + * @typedef odp_comp_compl_t
> +* Compression API completion event (platform dependent)
> +*/
> +
> +/**
> + * Compression API operation mode
> + */
> +typedef enum {
> +   /** Synchronous, return results immediately */
> +   ODP_COMP_SYNC,
> +   /** Asynchronous, return results via queue event */
> +   ODP_COMP_ASYNC,
> +} odp_comp_op_mode_t;
> +
> +/**
> + * Comp API operation type.
> + *
> + */
> +typedef enum {
> +   /** Compress and/or Compute digest  */
> +   ODP_COMP_OP_COMPRESS,
> +   /** Decompress and/or Compute digest */
> +   ODP_COMP_OP_DECOMPRESS,
> +} odp_comp_op_t;
> +
> +/**
> + * Comp API hash algorithm
> + *
> + */
> +typedef enum {
> +   /** ODP_COMP_HASH_ALG_NONE*/
> +   ODP_COMP_HASH_ALG_NONE,
> +   /** ODP_COMP_HASH_ALG_SHA1*/
> +   ODP_COMP_HASH_ALG_SHA1,
> +   /**  ODP_COMP_HASH_ALG_SHA256*/
> +   ODP_COMP_HASH_ALG_SHA256
> +} odp_comp_hash_alg_t;
> +
> +/**
> + * Comp API compression algorithm
> + *
> + */
> +typedef enum {
> +   /** No algorithm specified.
> +   * Means no compression, no output provided.
> +   */
> +   ODP_COMP_ALG_NULL,
> +   /** DEFLATE -
> +   * implicit Inflate in case of decode operation.
> +   */
> +   ODP_COMP_ALG_DEFLATE,
> +   /** ZLIB-RFC1950 */
> +   ODP_COMP_ALG_ZLIB,
> +   /** LZS*/
> +   ODP_COMP_ALG_LZS
> +} odp_comp_alg_t;
> +
> +/**
> + * Comp API session creation return code
> + *
> + */
> +typedef enum {
> +   /** Session created */
> +   ODP_COMP_SES_CREATE_ERR_NONE,
> +   /** Creation failed, no resources */
> +   ODP_COMP_SES_CREATE_ERR_ENOMEM,
> +   /** Creation failed, bad compression params */
> +   ODP_COMP_SES_CREATE_ERR_INV_COMP,
> +   /** Creation failed, bad hash params */
> +   ODP_COMP_SES_CREATE_ERR_INV_HASH,
> +   /** Creation failed,requested configuration not supported*/
> +   ODP_COMP_SES_CREATE_ERR_NOT_SUPPORTED
> +} odp_comp_ses_create_err_t;
> +
> +/**
> + * Comp API operation return codes
> + *
> + */
> +typedef enum {
> +   /** Operation completed successfully*/
> +   ODP_COMP_ERR_NONE,
> +   /** Invalid user data pointers*/
> +   ODP_COMP_ERR_DATA_PTR,
> +   /** Invalid input data size*/
> +   ODP_COMP_ERR_DATA_SIZE,
> +   /**  Compression and/or hash Algo failure*/
> +   ODP_COMP_ERR_ALGO_FAIL,
> +   /** Operation paused due to insufficient output buffer.
> +   *
> +   * This is not an error condition. On seeing this situation,
> +   * Implementation should maintain context of in-progress operation
> and
> +   * application should call packet processing API again with valid
> +   * output buffer but no other altercation to operation params
> 

[lng-odp] [RFC, API-NEXT v3 1/1] comp: compression interface

[Shally Verma]

Signed-off-by: Shally Verma <sve...@cavium.com>
Signed-off-by: Mahipal Challa <mcha...@cavium.com>
---
 include/odp/api/spec/comp.h | 740 
 1 file changed, 740 insertions(+)

diff --git a/include/odp/api/spec/comp.h b/include/odp/api/spec/comp.h
new file mode 100644
index 000..6c13ad4
--- /dev/null
+++ b/include/odp/api/spec/comp.h
@@ -0,0 +1,740 @@
+/*
+ */
+
+/**
+ * @file
+ *
+ * ODP Compression
+ */
+
+#ifndef ODP_API_COMP_H_
+#define ODP_API_COMP_H_
+
+#include 
+#include 
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/** @defgroup odp_compression ODP COMP
+ *  ODP Compression defines interface to compress/decompress along with hash
+ *  operations.
+ *
+ *  Compression here implicilty refer to both compression and decompression.
+ *  Example, compression algo 'deflate' mean both 'deflate' and 'inflate'.
+ *
+ *  if opcode = ODP_COMP_COMPRESS, then it will Compress and/or apply hash,
+ *  if opcode = ODP_COMP_DECOMPRESS, then it will Decompress and/or apply
+ *  hash.
+ *
+ *  Current version of interface allow Compression ONLY,and
+ *  both Compression + hash ONLY sessions.
+ *
+ *  Macros, enums, types and operations to utilise compression.
+ *  @{
+ */
+
+/**
+ * @def ODP_COMP_SESSION_INVALID
+ * Invalid session handle
+ */
+
+/**
+ * @typedef odp_comp_session_t (platform dependent)
+ * Comp API opaque session handle
+ */
+
+/**
+ * @typedef odp_comp_compl_t
+* Compression API completion event (platform dependent)
+*/
+
+/**
+ * Compression API operation mode
+ */
+typedef enum {
+   /** Synchronous, return results immediately */
+   ODP_COMP_SYNC,
+   /** Asynchronous, return results via queue event */
+   ODP_COMP_ASYNC,
+} odp_comp_op_mode_t;
+
+/**
+ * Comp API operation type.
+ *
+ */
+typedef enum {
+   /** Compress and/or Compute digest  */
+   ODP_COMP_OP_COMPRESS,
+   /** Decompress and/or Compute digest */
+   ODP_COMP_OP_DECOMPRESS,
+} odp_comp_op_t;
+
+/**
+ * Comp API hash algorithm
+ *
+ */
+typedef enum {
+   /** ODP_COMP_HASH_ALG_NONE*/
+   ODP_COMP_HASH_ALG_NONE,
+   /** ODP_COMP_HASH_ALG_SHA1*/
+   ODP_COMP_HASH_ALG_SHA1,
+   /**  ODP_COMP_HASH_ALG_SHA256*/
+   ODP_COMP_HASH_ALG_SHA256
+} odp_comp_hash_alg_t;
+
+/**
+ * Comp API compression algorithm
+ *
+ */
+typedef enum {
+   /** No algorithm specified.
+   * Means no compression, no output provided.
+   */
+   ODP_COMP_ALG_NULL,
+   /** DEFLATE -
+   * implicit Inflate in case of decode operation.
+   */
+   ODP_COMP_ALG_DEFLATE,
+   /** ZLIB-RFC1950 */
+   ODP_COMP_ALG_ZLIB,
+   /** LZS*/
+   ODP_COMP_ALG_LZS
+} odp_comp_alg_t;
+
+/**
+ * Comp API session creation return code
+ *
+ */
+typedef enum {
+   /** Session created */
+   ODP_COMP_SES_CREATE_ERR_NONE,
+   /** Creation failed, no resources */
+   ODP_COMP_SES_CREATE_ERR_ENOMEM,
+   /** Creation failed, bad compression params */
+   ODP_COMP_SES_CREATE_ERR_INV_COMP,
+   /** Creation failed, bad hash params */
+   ODP_COMP_SES_CREATE_ERR_INV_HASH,
+   /** Creation failed,requested configuration not supported*/
+   ODP_COMP_SES_CREATE_ERR_NOT_SUPPORTED
+} odp_comp_ses_create_err_t;
+
+/**
+ * Comp API operation return codes
+ *
+ */
+typedef enum {
+   /** Operation completed successfully*/
+   ODP_COMP_ERR_NONE,
+   /** Invalid user data pointers*/
+   ODP_COMP_ERR_DATA_PTR,
+   /** Invalid input data size*/
+   ODP_COMP_ERR_DATA_SIZE,
+   /**  Compression and/or hash Algo failure*/
+   ODP_COMP_ERR_ALGO_FAIL,
+   /** Operation paused due to insufficient output buffer.
+   *
+   * This is not an error condition. On seeing this situation,
+   * Implementation should maintain context of in-progress operation and
+   * application should call packet processing API again with valid
+   * output buffer but no other altercation to operation params
+   * (odp_comp_op_param_t).
+   *
+   * if using async mode, application should either make sure to
+   * provide sufficient output buffer size OR maintain relevant
+   * context (or ordering) information with respect to each input packet
+   * enqueued for processing
+   *
+   */
+   ODP_COMP_ERR_OUT_OF_SPACE,
+   /** Error if operation has been requested in an invalid state */
+   ODP_COMP_ERR_INV_STATE,
+   /** Error if API call does not input params or mode. */
+   ODP_COMP_ERR_NOT_SUPPORTED
+} odp_comp_err_t;
+
+/**
+* Comp API enumeration for preferred compression level/speed.
+*
+* trade-off between speed and compression ratio.
+*
+*/
+typedef enum {
+   /* Use implementaion default */
+   ODP_COMP_LEVEL_DEFAULT = 0,
+   /** Minimum compression (fastest in speed) */
+   ODP_COMP_LEVEL_MIN,
+   /** Maximum compression (slowest in speed) */
+   ODP_COMP_LEVEL_MA

[lng-odp] [RFC, API-NEXT v3 0/1] comp: compression interface API set

[Shally Verma]

An API set to support compression/decompression utility to ODP based 
compression Application.
Changes from V2:
Add seperate API for sync and async operation,
Add seperate API to load dictionary,
Remove SHA only support from compression interface,
Rename SHA operations as hash operation.
Add reference odp_packet_data_range_t for accessing packet buffer


Shally Verma (1):
  comp: compression interface

 include/odp/api/spec/comp.h | 740 
 1 file changed, 740 insertions(+)
 create mode 100644 include/odp/api/spec/comp.h

-- 
1.9.1

[lng-odp] [RFC, API-NEXT v2 1/1] comp:compression interface

[Shally Verma]

An API set to add compression/decompression support in ODP
interface.

Signed-off-by: Shally Verma <sve...@cavium.com>
Signed-off-by: Mahipal Challa <mcha...@cavium.com>
---
 include/odp/api/spec/comp.h | 748 
 1 file changed, 748 insertions(+)

diff --git a/include/odp/api/spec/comp.h b/include/odp/api/spec/comp.h
new file mode 100644
index 000..65feacf
--- /dev/null
+++ b/include/odp/api/spec/comp.h
@@ -0,0 +1,748 @@
+/*
+ */
+
+/**
+ * @file
+ *
+ * ODP Compression
+ */
+
+#ifndef ODP_API_COMP_H_
+#define ODP_API_COMP_H_
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/** @defgroup odp_compression ODP COMP
+ *  ODP Compression defines interface to compress/decompress and authenticate
+ *  data.
+ *
+ *  Compression here implicilty refer to both compression and decompression.
+ *  Example, compression algo 'deflate' mean both 'deflate' and 'inflate'.
+ *
+ *  if opcode = ODP_COMP_COMPRESS, then it will Compress,
+ *  if opcode = ODP_COMP_DECOMPRESS, then it will Decompress.
+ *
+ *  Current version of Interface allow Compression ONLY,Authentication ONLY or
+ *  both Compression + Auth ONLY sessions.
+ *
+ *  Macros, enums, types and operations to utilise compression.
+ *  @{
+ */
+
+/**
+ * @def ODP_COMP_SESSION_INVALID
+ * Invalid session handle
+ */
+
+/**
+ * @typedef odp_comp_session_t (platform dependent)
+ * Comp API opaque session handle
+ */
+
+/**
+ * @typedef odp_comp_compl_t
+* Compression API completion event (platform dependent)
+*/
+
+/**
+ * Compression API operation mode
+ */
+typedef enum {
+   /** Synchronous, return results immediately */
+   ODP_COMP_SYNC,
+   /** Asynchronous, return results via queue event */
+   ODP_COMP_ASYNC,
+} odp_comp_op_mode_t;
+
+/**
+ * Comp API operation type.
+ * Ignored for Authentication ONLY.
+ *
+ */
+typedef enum {
+   /** Compress and/or Compute digest  */
+   ODP_COMP_OP_COMPRESS,
+   /** Decompress and/or Compute digest */
+   ODP_COMP_OP_DECOMPRESS,
+} odp_comp_op_t;
+
+/**
+ * Comp API authentication algorithm
+ *
+ */
+typedef enum {
+   /** No authentication algorithm specified */
+   ODP_COMP_AUTH_ALG_NULL,
+   /** ODP_COMP_AUTH_ALG_SHA1*/
+   ODP_COMP_AUTH_ALG_SHA1,
+   /**  ODP_COMP_AUTH_ALG_SHA256*/
+   ODP_COMP_AUTH_ALG_SHA256
+} odp_comp_auth_alg_t;
+
+/**
+ * Comp API compression algorithm
+ *
+ */
+typedef enum {
+   /** No algorithm specified.
+   * Means no compression, no output provided.
+   */
+   ODP_COMP_ALG_NULL,
+   /** DEFLATE -
+   * implicit Inflate in case of decode operation.
+   */
+   ODP_COMP_ALG_DEFLATE,
+   /** ZLIB-RFC1950 */
+   ODP_COMP_ALG_ZLIB,
+   /** LZS*/
+   ODP_COMP_ALG_LZS,
+} odp_comp_alg_t;
+
+/**
+ * Comp API session creation return code
+ *
+ */
+typedef enum {
+   /** Session created */
+   ODP_COMP_SES_CREATE_ERR_NONE,
+   /** Creation failed, no resources */
+   ODP_COMP_SES_CREATE_ERR_ENOMEM,
+   /** Creation failed, bad compression params */
+   ODP_COMP_SES_CREATE_ERR_INV_COMP,
+   /** Creation failed, bad auth params */
+   ODP_COMP_SES_CREATE_ERR_INV_AUTH,
+   /** Creation failed,requested configuration not supported*/
+   ODP_COMP_SES_CREATE_ERR_NOT_SUPPORTED
+} odp_comp_ses_create_err_t;
+
+/**
+ * Comp API operation return codes
+ *
+ */
+typedef enum {
+   /** Operation completed successfully*/
+   ODP_COMP_ERR_NONE,
+   /** Invalid user data pointers*/
+   ODP_COMP_ERR_DATA_PTR,
+   /** Invalid input data size*/
+   ODP_COMP_ERR_DATA_SIZE,
+   /**  Compression and/or Auth Algo failure*/
+   ODP_COMP_ERR_ALGO_FAIL,
+   /** Error detected during DMA of data*/
+   ODP_COMP_ERR_DMA,
+   /** Operation paused due to insufficient output buffer
+   *
+   * This is not an error condition. On seeing this error, caller
+   * should call odp_comp_operation() again with valid output buffer
+   * with no-more input or altercation to other input
+   * operation parameters.
+   *
+   * for applications, considering this an error condition should destroy
+   * and re-create session to start afresh.
+   *
+   * Implementation should maintain context in this condition.
+   */
+   ODP_COMP_ERR_OUT_OF_SPACE,
+   /** Error if operation has been requested in an invalid state */
+   ODP_COMP_ERR_INV_STATE
+} odp_comp_err_t;
+
+/**
+* Comp API enumeration for preferred compression level/speed.
+*
+* trade-off between speed and compression ratio.
+*
+* Please note this enumeration is only a peferential selection
+* but may not guarantee operation to committed level depending
+* on implementation support. Ex. SPEED_FASTEST and SPEED_FAST may
+* give same result on some platforms.
+*
+*/
+typedef enum {
+   /* Use implementaion default between ratio and speed */
+   ODP_

[lng-odp] [RFC, API-NEXT v2 0/1] comp:compression interface

[Shally Verma]

This series adds an API set to support compression/decompression in ODP 
interface.
Changes from patch v1:
make compression and authentication algorithms as seperate enumerations, 
dedicate session to be either as synchronous or asynchronous, 
indicate interface support for sync/async in capability struct

Shally Verma (1):
  odp compression interface api set

 include/odp/api/spec/comp.h | 748 
 1 file changed, 748 insertions(+)
 create mode 100644 include/odp/api/spec/comp.h

-- 
1.9.1