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

Ahmed Mansour ahmed.mansour at nxp.com
Thu Feb 1 21:50:29 CET 2018


>>> [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?



More information about the dev mailing list