Re: [RFC] CryptoAPI & Compression

[Herbert Xu]

On Sun, Apr 03, 2005 at 11:06:01AM +0100, David Woodhouse wrote:
> 
> We're not interested in the _total_ overhead, in this context. We're
> interested in the number of bytes we have to have available in the
> output buffer in order to let zlib finish its stream.
> 
> In the case of a 1MiB input generating 32 uncompressable 64KiB blocks,
> the end markers for the first 31 blocks are going to be in our output
> buffer already, so we don't need to leave space for them.

You might be right.  But I'm not sure yet.

If we use the current code and supply zlib_deflate with 1048576-12 bytes
of (incompressible) input and 1048576 bytes of output buffer, wouldn't
zlib keep writing incompressible blocks and return when it can't do that
anymore because the output buffer has been exhausted?

When it does return it has to finish writing the last block it's on.

So if the total overhead is 32 bytes then the last block would need
another 20 bytes of output space which we don't have, no?

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/