Petri Savolainen(psavol) replied on github web page:
include/odp/api/spec/comp.h
line 30
@@ -0,0 +1,873 @@
+/* Copyright (c) 2017, Linaro Limited
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+/**
+ * @file
+ *
+ * ODP Compression
+ */
+
+#ifndef ODP_API_COMP_H_
+#define ODP_API_COMP_H_
+
+#include <odp/visibility_begin.h>
+#include <odp/api/support.h>
+#include <odp/api/packet.h>
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/** @defgroup odp_compression ODP COMP
+ * ODP Compression is an API set to do compression+hash or decompression+hash
+ * operations on data. Hash is calculated on plaintext.
+ *
+ * if opcode = ODP_COMP_COMPRESS, then it will apply hash and then compress,
+ * if opcode = ODP_COMP_DECOMPRESS, then it will decompress and then apply
+ * hash.
Comment:
E.g. move to odp_comp_op() documentation (in this file) and then refer to that
from other comp operation functions.
> Petri Savolainen(psavol) wrote:
> It looks like OUT_OF_SPACE causes too much controversity ATM. I would suggest
> to make it a hard error at this point, merge API w/o out-of-space, then
> rethink this particular item. Partially processed packets need additional
> thought with respect to state being saved/passed back/etc.
>> Petri Savolainen(psavol) wrote:
>> Does the partially processed packet contain valid data or not == does
>> application keep or discard the packet?
>> Shally > It will be a valid data and thus application is supposed to consume
>> it.
>> Is there any way for application to prepare large enough packet in advance?
>> Shally > Its more of application dependent such as ipcomp it knows packet
>> cannot go beyond a maximum length of IP Packet.
>> E.g. a per algo capability of worst case decompression ratio?
>> Shally > No. it is not guaranteed. Its more of data type property and
>> algorithm capability.
>> Should "pkt_out = INVALID" be supported?
>> Shally > No.
>> implementation allocates large enough packet.
>> Shally > we refrained from this approach as in such case implementation may
>> end up eating whole of user pool. Better approach is pass back what ever is
>> available at output. Now, application may consume it and reuse same packet
>> for next o/p OR extend the packet by some length (say double it up).
>> Single packet handle should be defined as const.
>> Shally > It is const in API param list ... odp_comp_op(const odp_packet_t
>> pkt_in....) .. what am i missing here?
>> There is out_data_range defined in both op_param_t and op_result_t. Which
>> one is updated on output?
>> Shally> One in op_result.
>> May be operation output comments should be removed from op_param_t
>> documentation.
>> Shally > Yea. Did that already.
>>
>> Please mark your approval to these.
>>> Petri Savolainen(psavol) wrote:
>>> ... with valid pkt_out and pkt_in being ODP_PACKET_INVALID...
>>> >> No. pkt_in too has to be valid and untouched. It is quite possible, that
>>> >> algorithm may or may not consume full input from input buffer when it
>>> >> hit out of buffer situation. Thus, none of the parameters except output
>>> >> packet should be updated by application until fully process and that's
>>> >> why description says " 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 alteration to operation params
>>> * (odp_comp_op_param_t)."
>>>> Petri Savolainen(psavol) wrote:
>>>> default values are implementation dependent. There's no standard what they
>>>> could be set to. Example, one implementation may set default comp_alg to
>>>> zlib and other to deflate or possibly any other to zlib+hash. So, we
>>>> cannot document here what default values should be.
>>>>> Petri Savolainen(psavol) wrote:
>>>>> Can this return more than one hash_alg_capa (== digest_len) per hash_alg?
>>>>> >>No. ideally, an implementation should return only 1 single capability
>>>>> >>per hash algorithm. I cannot think why a valid implementation would
>>>>> >>return more than 1 capability according to capability structure we have
>>>>> >>here.
>>>>> This API signature has been retained to keep consistency with other
>>>>> interface capability API.
>>>>>> Petri Savolainen(psavol) wrote:
>>>>>> offset is not updated by spec as compression does not support
>>>>>> auto-allocation of packet and starts data write at given offset only.
>>>>>> For description, I rephrased it as below.
>>>>>> " /** Output packet data range.
>>>>>> *
>>>>>> * out_data_range.offset = offset in output packet data buffer to start
>>>>>> * write at,
>>>>>> *
>>>>>> * out_data_range.length = length of available space for output
>>>>>> * from given offset.
>>>>>> *
>>>>>> */
>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>> Ok.
>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>> "then we should document that the value is ignored."
>>>>>>>> >> Sorry, I didn't get that. You referring to which value to be
>>>>>>>> >> ignored?
>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>> Did you refer to note starting here " * Please note, behavior could
>>>>>>>>> be changed or enhanced........"? if yes, okay I will remove that
>>>>>>>>> text. Please confirm.
>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>> accepted.
>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>> 1.comp_algo is always set. It should be e.g. ALG_NULL by default.
>>>>>>>>>>> >> I am bit confused. Are you suggesting adding a description to
>>>>>>>>>>> >> "comp ALG_NULL+hash"? We agreed in past that " user must use
>>>>>>>>>>> >> crypto for standalone hashing and compression algo NULL is only
>>>>>>>>>>> >> for testing purpose" and current description on usage of hash
>>>>>>>>>>> >> and ALG_NULL abide that. So, we can leave current description
>>>>>>>>>>> >> as is.
>>>>>>>>>>> 2. What this means: "output should always contain data + hash" ? If
>>>>>>>>>>> we enable hashing, hash is always calculated. It's not optional for
>>>>>>>>>>> implementation to calculate it - right.
>>>>>>>>>>> >> I will rephrase it to "output *will* always contain data +
>>>>>>>>>>> >> hash".
>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>> " This should be specified at operation documentation" means which
>>>>>>>>>>>> place? user guide Or ?
>>>>>>>>>>>>
>>>>>>>>>>>> Do you mean I should remove this description from here? Or
>>>>>>>>>>>> "+ * if opcode = ODP_COMP_COMPRESS, then it will apply hash and
>>>>>>>>>>>> then compress,
>>>>>>>>>>>> + * if opcode = ODP_COMP_DECOMPRESS, then it will decompress and
>>>>>>>>>>>> then apply
>>>>>>>>>>>> + * hash."
>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>> First, async call can reuse sync call spec by saying: "...
>>>>>>>>>>>>> processes packets otherwise identically to odp_comp_op(), but
>>>>>>>>>>>>> outputs resulting packets as ODP_EVENT_PACKET events ...". Then
>>>>>>>>>>>>> the remaining text can concentrate on what is unique on async vs
>>>>>>>>>>>>> sync operation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think OUT_OF_SPACE spec might need re-thinking:
>>>>>>>>>>>>> 1) user sees a partial packet (error on a received packet)
>>>>>>>>>>>>> 2) implementation waits that user calls op_enq() again
>>>>>>>>>>>>> 3) what input packet should be given on the new call? I think the
>>>>>>>>>>>>> previous operation already consumed the input packet which
>>>>>>>>>>>>> contains the input data for operation. Did implementation store
>>>>>>>>>>>>> it?
>>>>>>>>>>>>> 4) how long implementation waits for new output packet to arrive
>>>>>>>>>>>>> from user, what if user don't send new output packets.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Async spec (and also sync) spec would be more robust if
>>>>>>>>>>>>> implementation would allocate output packets.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>> Application does not allocate buffers but packets.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Does the partially processed packet contain valid data or not ==
>>>>>>>>>>>>>> does application keep or discard the packet?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is there any way for application to prepare large enough packet
>>>>>>>>>>>>>> in advance? E.g. a per algo capability of worst case
>>>>>>>>>>>>>> decompression ratio? Should "pkt_out = INVALID" be supported?
>>>>>>>>>>>>>> ==> implementation allocates large enough packet.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Single packet handle should **not** be defined as const.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> There is out_data_range defined in both op_param_t and
>>>>>>>>>>>>>> op_result_t. Which one is updated on output? May be operation
>>>>>>>>>>>>>> output comments should be removed from op_param_t documentation.
>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>> Simply say that:
>>>>>>>>>>>>>>> This operation does de/-compression in synchronous mode
>>>>>>>>>>>>>>> (ODP_COMP_SYNC).
>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>> "implementation should update length of dictionary used at
>>>>>>>>>>>>>>>> output."
>>>>>>>>>>>>>>>> This is too vague: either length is updated or it's not. In
>>>>>>>>>>>>>>>> which cases the update would be done and what that would mean?
>>>>>>>>>>>>>>>> Also, I assume that implementation copies the data, so that
>>>>>>>>>>>>>>>> application is free to overwrite the memory after the call.
>>>>>>>>>>>>>>>> That (copies data) should be mentioned also.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Is there a benefit on output param here, especially if it
>>>>>>>>>>>>>>>> updates only the length and not the pointer. Maybe API would
>>>>>>>>>>>>>>>> be cleaner, if also *dict is input only param (and thus
>>>>>>>>>>>>>>>> const*). Function may return e.g. number of bytes copied/used.
>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>> This can be simply
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> odp_comp_session_t odp_comp_session_create(const
>>>>>>>>>>>>>>>>> odp_comp_session_param_t *param)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Extra error codes may be returned through odp_errno().
>>>>>>>>>>>>>>>>> Usually, we have not defined error codes, since it's
>>>>>>>>>>>>>>>>> implementation defines what all things can possibly go wrong,
>>>>>>>>>>>>>>>>> and typically application logic is just interested on success
>>>>>>>>>>>>>>>>> vs fail - not so much why we failed.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This function prototype is copy-paste from crypto API, but
>>>>>>>>>>>>>>>>> all other APIs are the type I suggested above.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Note: const pointer for "param"
>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>> It would be good to define default values for
>>>>>>>>>>>>>>>>>> odp_comp_session_param_t (at the type documentation).
>>>>>>>>>>>>>>>>>> Otherwise, application needs to always set every param.
>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>> Can this return more than one hash_alg_capa (== digest_len)
>>>>>>>>>>>>>>>>>>> per hash_alg? Currently, application cannot select digest
>>>>>>>>>>>>>>>>>>> length. So, what application should do if this returns more
>>>>>>>>>>>>>>>>>>> than one capa.
>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>> Is array of capabilities needed with comp algorithms? It
>>>>>>>>>>>>>>>>>>>> would be needed if user would need to select between
>>>>>>>>>>>>>>>>>>>> multiple discrete options - e.g. if only some dict_len
>>>>>>>>>>>>>>>>>>>> values would make sense (1kB, 4kB, 16kB), but nothing in
>>>>>>>>>>>>>>>>>>>> between.
>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>> "where length specifies,
>>>>>>>>>>>>>>>>>>>>> length of available packet buffer at input, and
>>>>>>>>>>>>>>>>>>>>> length of data written at output"
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> This specification should be clarified. "Input" refers
>>>>>>>>>>>>>>>>>>>>> refers to out_data_range.length as operation input param
>>>>>>>>>>>>>>>>>>>>> and "output" refers to the same as operation output
>>>>>>>>>>>>>>>>>>>>> parameter.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> In addition to length, offset may be updated at operation
>>>>>>>>>>>>>>>>>>>>> output (at least when new packet was allocated). That
>>>>>>>>>>>>>>>>>>>>> should be mentioned also.
>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>> This last chuck:
>>>>>>>>>>>>>>>>>>>>>> "In case of
>>>>>>>>>>>>>>>>>>>>>> ODP_COMP_ERR_OUT_OF_SPACE, application should keep on
>>>>>>>>>>>>>>>>>>>>>> calling
>>>>>>>>>>>>>>>>>>>>>> odp_comp_xxx() API with more output buffer unless call
>>>>>>>>>>>>>>>>>>>>>> returns
>>>>>>>>>>>>>>>>>>>>>> with ODP_COMP_ERR_NONE or other failure code except
>>>>>>>>>>>>>>>>>>>>>> ODP_COMP_ERR_OUT_OF_SPACE. "
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Documents operation return / error codes rather than
>>>>>>>>>>>>>>>>>>>>>> "last" field usage. So, I'd remove it from here.
>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>> If only option for a stateless algorithm is true, then
>>>>>>>>>>>>>>>>>>>>>>> we should document that the value is ignored.
>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Typo: "enques" -> enqueues"
>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> Remove this block text since it's speculation of what
>>>>>>>>>>>>>>>>>>>>>>>>> could be specified.
>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> Typo: "... given as comp_alg" -> "... given as
>>>>>>>>>>>>>>>>>>>>>>>>>> comp_algo"
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> There are two SHOULDs, but I think those are not
>>>>>>>>>>>>>>>>>>>>>>>>>> needed:
>>>>>>>>>>>>>>>>>>>>>>>>>> 1) comp_algo is always set. It should be e.g.
>>>>>>>>>>>>>>>>>>>>>>>>>> ALG_NULL by default. We have defined that NULL does
>>>>>>>>>>>>>>>>>>>>>>>>>> not have hash capability. It would be also possible
>>>>>>>>>>>>>>>>>>>>>>>>>> to leave NULL + hash to be implementation defined
>>>>>>>>>>>>>>>>>>>>>>>>>> capability. When we say that ALG_NULL is only for
>>>>>>>>>>>>>>>>>>>>>>>>>> test, it should be enough to discourage people from
>>>>>>>>>>>>>>>>>>>>>>>>>> misusing this API for hashing.
>>>>>>>>>>>>>>>>>>>>>>>>>> 2) What this means: "output should always contain
>>>>>>>>>>>>>>>>>>>>>>>>>> data + hash" ? If we enable hashing, hash is always
>>>>>>>>>>>>>>>>>>>>>>>>>> calculated. It's not optional for implementation to
>>>>>>>>>>>>>>>>>>>>>>>>>> calculate it - right.
>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> Field name should match the type == "hash_algos"
>>>>>>>>>>>>>>>>>>>>>>>>>>> (many algorithms in a bit field). Underneath
>>>>>>>>>>>>>>>>>>>>>>>>>>> "hash_algo" is used with enum odp_comp_hash_alg_t
>>>>>>>>>>>>>>>>>>>>>>>>>>> (one algo).
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> I did comment the same a month back:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Is the data input only? If it is, then this should
>>>>>>>>>>>>>>>>>>>>>>>>>>>> be "const uint8_t *buf"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> What is expected about the format of the data?
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Null terminated strings? If it's strings, then
>>>>>>>>>>>>>>>>>>>>>>>>>>>> e.g. "const char *str" would be better.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Also the type documentation should be updated:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> * This is not dictionary type, but pointer into
>>>>>>>>>>>>>>>>>>>>>>>>>>>> dictionary data - right?
>>>>>>>>>>>>>>>>>>>>>>>>>>>> * "Consists of pointer to byte buffer. length of
>>>>>>>>>>>>>>>>>>>>>>>>>>>> dictionary indicated by length parameter. ", this
>>>>>>>>>>>>>>>>>>>>>>>>>>>> needs clarification. What is expected about the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> data behind the pointer?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> @psavol Hmm. I thought that the user should use
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this value. And `odp_comp_level_t` should be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dropped from the spec.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How this relates to odp_comp_level_t enumeration
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ? Shouldn't user use those levels and not a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> number from 0 to this one ?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This is description of how de/-compression
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> operation work. This should be specified at
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> operation documentation, and optimally only
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> there. Otherwise, we are in danger of this spec
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> getting deprecated (== in conflict with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> operation documentation) without noticing.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> True, all types need to be odp_ prefixed. Also
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this type would be better to typedef and pull
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> out (from inside of algo_param_t) since it's
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> used in two places already.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> As a side note: it might be logical, we might
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> want to add `odp_support_t` field to notify
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> user if implementation supports stateful
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> compression. I can easily assume that there
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> might be implementations implementing only
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stateless compression.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> odp_comp_alg_deflate_param, please.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please check the see list. It mentions
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-existing functions.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> no result here
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> s/Else/Otherwise/
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ... an error....
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ... with valid pkt_out and pkt_in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> being ODP_PACKET_INVALID...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is an error to call this api when
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> session was created in ODP_COMP_ASYNC
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mode.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> As said, single and multi versions
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are possible, but not as proposed in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this patch. Both versions should have
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the same param structure and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> specification. Only difference would
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be pkt_in[] vs pkt_in, pkt_out[] vs
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pkt_out, param[] vs. param ...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Then I propose to add a new API like
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> odp_comp_compress_multi(const
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> odp_packet_t pkt_in[], odp_packet_t
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pkt_out[], const
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> odp_comp_compress_param_t param[],
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int num_pkt);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which takes of handling multiple
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> packets and retain current version
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for single packet handling.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Shally
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> @bala-manoharan
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Results for both sync and async
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> through result function:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> odp_comp_result(odp_comp_packet_result_t
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> *result, odp_packet_t packet);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> OR have the results as output
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> parameter. Results function is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> needed any way for the async
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> operation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int odp_comp_compress(const
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> odp_packet_t pkt_in[],
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> odp_packet_t pkt_out[], const
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> odp_comp_compress_param_t param[],
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int num_pkt);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Single packet version may be also
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> added, but is not necessary since
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> couple of additional if-clauses
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does not significant overhead when
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> compare CPU cycles of the entire
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> comp operation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> odp_comp_compress_single(odp_packet_t
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pkt_in, odp_packet_t pkt_out,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> const odp_comp_compress_param_t
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> param);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The two prototypes would be the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> same except [] and num_pkt.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
https://github.com/Linaro/odp/pull/156#discussion_r137771361
updated_at 2017-09-08 11:49:54
