Re: [RFC] CryptoAPI & Compression

[David Woodhouse]

On Sun, 2005-04-03 at 20:00 +1000, Herbert Xu wrote:
> > 1. 64K is only applied to non-compressible data, in which case zlib just 
> > copies it as it is, adding a 1-byte header and a 1-byte EOB marker.
> 
> I think the overhead could be higher.  But even if it is 2 bytes
> per block, then for 1M of incompressible input the total overhead is
> 
> 2 * 1048576 / 65536 = 32

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.

-- 
dwmw2

-
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/