Re: [lng-odp] [COMPRESSION,RFCv1]

Thanks Barry. Will go through these. Thanks Shally -Original Message- From: Barry Spinney [mailto:spin...@mellanox.com] Sent: 09 September 2017 03:37 To: lng-odp@lists.linaro.org Cc: Bill Fischofer <bill.fischo...@linaro.org>; Verma, Shally <shally.ve...@cavium.com>; B

[lng-odp] Regarding github pull (RE: [Linaro/odp] [PATCH API-NEXT v12] comp: compression spec (#102))

t;o...@noreply.github.com> Cc: Verma, Shally <shally.ve...@cavium.com>; Your activity <your_activ...@noreply.github.com> Subject: Re: [Linaro/odp] [PATCH API-NEXT v12] comp: compression spec (#102) Yea I realise that part and I tried to squash them however since I am new to github so taking

Re: [lng-odp] api-next broken?

-Original Message- From: Dmitry Eremin-Solenikov [mailto:dmitry.ereminsoleni...@linaro.org] Sent: 31 August 2017 16:13 To: shally verma <shallyvermacav...@gmail.com>; lng-odp-forward <lng-odp@lists.linaro.org> Cc: Pimpalkar, Shrutika <shrutika.pimpal...@cavium.com&

Re: [lng-odp] Regarding github pull request

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

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

asad 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 Ver

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

adathreya.naray...@cavium.com>; Verma, Shally <shally.ve...@cavium.com> Subject: Re: [lng-odp] [RFC, API-NEXT v3 1/1] comp: compression interface On 22.05.2017 09:54, Shally Verma wrote: > Signed-off-by: Shally Verma <sve...@cavium.com> > Signed-off-by: Mahipal Challa <mch

Re: [lng-odp] [Bug 2895] odp_crypto_operation() does not work with multi-segment packets

-Original Message- From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of bugzilla-dae...@bugs.linaro.org Sent: 22 May 2017 11:09 To: lng-odp@lists.linaro.org Subject: [lng-odp] [Bug 2895] odp_crypto_operation() does not work with multi-segment packets

Re: [lng-odp] [API-NEXT PATCH] api: packet: introduce odp_packet_data_range_t

Hi Dmitry We are okay with proposed change. We will change compression interface accordingly. Any idea when is it planned to be accepted and merged in api-next.? Thanks Shally -Original Message- From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Verma, Shally Sent

Re: [lng-odp] [API-NEXT PATCH] api: packet: introduce odp_packet_data_range_t

-Original Message- From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Dmitry Eremin-Solenikov Sent: 25 April 2017 22:01 To: lng-odp@lists.linaro.org Subject: [lng-odp] [API-NEXT PATCH] api: packet: introduce odp_packet_data_range_t Rename odp_crypto_data_range_t to

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

-Original Message- From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Verma, Shally Sent: 19 April 2017 19:30 To: Dmitry Eremin-Solenikov <dmitry.ereminsoleni...@linaro.org>; Shally Verma <shally.ve...@gmail.com>; lng-odp@lists.linaro.org Cc: Cha

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

.com>; Narayana, Prasad Athreya <prasadathreya.naray...@cavium.com>; Verma, Shally <shally.ve...@cavium.com> Subject: Re: [lng-odp] [RFC, API-NEXT v2 1/1] comp:compression interface On 19.04.2017 13:00, Shally Verma wrote: > An API set to add compression/decompression support

Re: [lng-odp] [Linaro/odp] 6ce267: Revert "api: ipsec: factor out definitions for fea...

I was preparing for compression patch2 and updated it today again to use odp_feature_t to indicate sync/async in capability (as per last but one check-in). So what is the proposal meanwhile? Should we instead use odp_bool_t to indicate feature (like async/sync mode) support until it is

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

-Original Message- From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Yi He Sent: 11 April 2017 19:36 To: lng-odp Subject: Re: [lng-odp] [API-NEXT PATCHv2 00/23] driver items registration and probing Hi, team Today in odp cloud meeting we

Re: [lng-odp] [API-NEXT] API: IPSEC: Updating ipsec APIs to support sNIC implementation.

-Original Message- From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Nikhil Agarwal Sent: 07 April 2017 15:30 To: lng-odp@lists.linaro.org Subject: [lng-odp] [API-NEXT] API: IPSEC: Updating ipsec APIs to support sNIC implementation. Signed-off-by: Nikhil Agarwal

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

We are sharing an Overview document of patch V1 based comp interface https://docs.google.com/document/d/1aaEo8oTvZvm2096GJzl165L571tcsKqfcaD5yypiiCA/edit?usp=sharing . It outlines possible applications, expected API usage and few key points. Please give your suggestions/comment w.r.t this to

[lng-odp] CRC/Adler requirement in comp interface

from yesterday meeting minutes , I see a note on this feedback on compression: Consider adding additional "hashes" (e.g., CRC, Adler) As we mentioned that comp interface does not provide CRC. Also adler comes as output of zlib format and CRC can be available through helper functions. So is

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

Please see in-line. -Original Message- From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bogdan Pricope Sent: 22 March 2017 14:17 To: Mahipal Challa Cc: Narayana, Prasad Athreya ; Masood, Faisal

Re: [lng-odp] Regarding Chained Buffers and Crypto

Have a question by chained , do you mean a "Segmented" packets? -Original Message- From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bala Manoharan Sent: 16 March 2017 14:01 To: Nanda Gopal Cc: lng-odp-forward Subject:

Re: [lng-odp] Generic handle in ODP

Humm. I see that a valid point. Yes I agree this proposal will add limitations on implementations and app. Thanks everyone for your time. From: Francois Ozog [mailto:francois.o...@linaro.org] Sent: 02 March 2017 14:44 To: Verma, Shally <shally.ve...@cavium.com> Cc: Maxim Uvarov <

Re: [lng-odp] Generic handle in ODP

s of data and avoiding code duplicity. Thanks Shally > On Wed, Mar 1, 2017 at 5:56 AM, Verma, Shally > <shally.ve...@cavium.com> > wrote: > >> Francois >> >> It is base assumption that an ODP Interface/implementation supporting >> generic handle c

Re: [lng-odp] Generic handle in ODP

but thinking if flexibility of having generic handle in ODP helps in flexible implementation where ever it is desirable / needed (of course with due care). Thanks Shally From: Francois Ozog [mailto:francois.o...@linaro.org] Sent: 01 March 2017 16:22 To: Verma, Shally <shally.ve...@cavium.com&

Re: [lng-odp] Generic handle in ODP

HI Petri/Maxim Please see my response below. -Original Message- From: Savolainen, Petri (Nokia - FI/Espoo) [mailto:petri.savolai...@nokia-bell-labs.com] Sent: 01 March 2017 14:38 To: Verma, Shally <shally.ve...@cavium.com>; Francois Ozog <francois.o...@linaro.org>

Re: [lng-odp] Generic handle in ODP

addr=odp_packet_data((odp_packet_t)handle); memcpy(dst,addr,len); } Hope this could explain intended use case to an extent. Thanks Shally From: Francois Ozog [mailto:francois.o...@linaro.org] Sent: 01 March 2017 13:28 To: Verma, Shally <shally.ve...@cavium.com> Cc: lng-odp@lists.lina

[lng-odp] Generic handle in ODP

I wanted to check if we could introduce a generic handle concept in ODP (something like odp_handle_t carrying purpose similar to void * ) which can be used for API that need to handle multiple types in one call. Ex. an API that works on both Packet and Buffer Type .Such use cases can take

Re: [lng-odp] odp_buffer_t usage

From: Bill Fischofer [mailto:bill.fischo...@linaro.org] Sent: 23 February 2017 18:17 To: Verma, Shally <shally.ve...@cavium.com> Cc: lng-odp@lists.linaro.org Subject: Re: [lng-odp] odp_buffer_t usage On Thu, Feb 23, 2017 at 6:28 AM, Verma, Shally <shally.ve...@cavium.com<mail

Re: [lng-odp] odp_buffer_t usage

From: Bill Fischofer [mailto:bill.fischo...@linaro.org] Sent: 23 February 2017 17:51 To: Verma, Shally <shally.ve...@cavium.com> Cc: lng-odp@lists.linaro.org Subject: Re: [lng-odp] odp_buffer_t usage ODP pools provide an abstraction for various types of managed storage. There are cur

[lng-odp] odp_buffer_t usage

Hi I was looking into odp_buffer_t to understand its use case from Application stand point. While it is clear for odp_packet_t description that it can be segmented/non-segmented contiguous / non-contiguous memory and APIs are provided to query and hop across segments to access data, but It is

[lng-odp] FW: odp-crypto operations for segmented packets.

Hi I was looking at linux-generic/odp_crypto.c implementation and it looks like that each odp_crypto_operation() call assumes that each Packet is contained within 1-segment or user passing either packet or segment len, whichever is smaller. As I understand ODP Packet structure, it is