Re: [dpdk-dev] [RFC v2] doc compression API for DPDK

[Ahmed Mansour <ahmed.mansour@nxp.com>]

>>> [Fiona] I propose if BFINAL bit is detected before end of input
>>> the decompression should stop. In this case consumed will be < src.length.
>>> produced will be < dst buffer size. Do we need an extra STATUS response?
>>> STATUS_BFINAL_DETECTED  ?
>> [Shally] @fiona, I assume you mean here decompressor stop after processing Final block right?
> [Fiona] Yes.
>
>  And if yes,
>> and if it can process that final block successfully/unsuccessfully, then status could simply be
>> SUCCESS/FAILED.
>> I don't see need of specific return code for this use case. Just to share, in past, we have practically run into
>> such cases with boost lib, and decompressor has simply worked this way.
> [Fiona] I'm ok with this.
>
>>> Only thing I don't like this is it can impact on performance, as normally
>>> we can just look for STATUS == SUCCESS. Anything else should be an exception.
>>> Now the application would have to check for SUCCESS || BFINAL_DETECTED every time.
>>> Do you have a suggestion on how we should handle this?
>>>
>
[Ahmed] This makes sense. So in all cases the PMD should assume that it
should stop as soon as a BFINAL is observed.

A question. What happens ins stateful vs stateless modes when
decompressing an op that encompasses multiple BFINALs. I assume the
caller in that case will use the consumed=x bytes to find out how far in
to the input is the end of the first stream and start from the next
byte. Is this correct?