Received-SPF: pass (google.com: domain of linux-crypto+bounces-3053-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Thu, 28 Mar 2024 19:46:47 -0700
From: Eric Biggers <ebiggers@kernel.org>
To: Andre Glover <andre.glover@linux.intel.com>
Cc: tom.zanussi@linux.intel.com, herbert@gondor.apana.org.au,
	davem@davemloft.net, dave.jiang@intel.com, fenghua.yu@intel.com,
	wajdi.k.feghali@intel.com, james.guilford@intel.com,
	vinodh.gopal@intel.com, tony.luck@intel.com,
	linux-crypto@vger.kernel.org, dmaengine@vger.kernel.org
Subject: Re: [PATCH 0/4] crypto: Add new compression modes for zlib and IAA
Message-ID: <20240329024647.GA20263@sol.localdomain>
References: <cover.1710969449.git.andre.glover@linux.intel.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cover.1710969449.git.andre.glover@linux.intel.com>

On Thu, Mar 28, 2024 at 10:44:41AM -0700, Andre Glover wrote:
> The 'canned' compression mode implements a compression scheme that
> uses a statically defined set of Huffman tables, but where the Deflate
> Block Header is implied rather than stored with the compressed data. 

This already exists in standard DEFLATE; it's called fixed mode.  See section
3.2.6 of RFC1951 (https://datatracker.ietf.org/doc/html/rfc1951#page-12).

I think that what's going on is that you've implemented a custom variant of
DEFLATE where you set the fixed Huffman codes to something different from the
ones defined in the standard.

Is that correct, or are there other differences?

Actually, looking at your zlib_tr_flush_block(), it looks instead of using the
reserved block type value (3) or redefining the meaning of the fixed block type
value (1), you actually deleted the BTYPE and BFINAL fields from the data stream
entirely.  So the stream no longer stores the type of block or the flag that
indicates whether the block is the final one or not.

That has the property that there cannot be any standard blocks, even
uncompressed blocks, included in the data stream anymore.  Is that intentional?

Maybe this is why you're using the name "canned", instead of going with
something more consistent with the existing "fixed" name, like "custom-fixed"?

I wonder what the plan is for when the next hardware vendor tries to do this and
chooses their own Huffman codes, different from yours.  Or what if Intel decides
the Huffman codes they chose aren't the best ones anymore and releases new
hardware that uses different codes.  Will we perhaps be getting a tinned mode
too?

Is your customization described in any sort of publicly available document that
could hint at some way to name it properly?

- Eric