I cannot really speak for OFP but OFP is not even using the compression API.

I do not really have an opinion one way or the other. Moving digest to 
odp_comp_packet_result_t does sound a little more flexible and maybe the 
overhead is not too bad with --disable-abi-compat.


From: Bill Fischofer <bill.fischo...@linaro.org>
Sent: Monday, December 10, 2018 11:27 PM
To: Dmitry Eremin-Solenikov <dmitry.ereminsoleni...@linaro.org>; Peltonen, 
Janne (Nokia - FI/Espoo) <janne.pelto...@nokia.com>
Cc: lng-odp-forward <lng-odp@lists.linaro.org>
Subject: Re: [lng-odp] Compression API: hashing

I'd like to hear from Janne as to what OFP would prefer. I'll also add this to 
the discussion agenda for tomorrow's public call. Thanks.

On Mon, Dec 10, 2018 at 2:28 PM Dmitry Eremin-Solenikov 
On 10/12/2018 22:11, Bill Fischofer wrote:
> I assume that's an API change? Can you put together a draft PR of what
> what would look like that we can discuss?

I can sketch a draft PR, however I'd like to hear an opinion first.

Basically my suggestion is to move digest from packet data to
odp_comp_packet_result_t. This will result in extra API call being
necessary to access digest data.

> On Mon, Dec 10, 2018 at 1:00 PM Dmitry Eremin-Solenikov
> <dmitry.ereminsoleni...@linaro.org<mailto:dmitry.ereminsoleni...@linaro.org>
> <mailto:dmitry.ereminsoleni...@linaro.org<mailto:dmitry.ereminsoleni...@linaro.org>>>
>  wrote:
>     Hello,
>     I have been reworking compression API implementation to properly
>     allocate/deallocate memory. Right now I've stumbled upon digest part of
>     compression API. Currently on both compression and decompression digest
>     should be written after co/decompressed output data. However both our
>     hardware and current DPDK compressdev use out-of-band data to pass
>     resulting hash. Do we want to stick with in-package data or do we want
>     to switch to OOB way to return message digest?
>     --
>     With best wishes
>     Dmitry

With best wishes

Reply via email to