From: Herbert Xu <herbert@gondor.apana.org.au>
To: Joonsoo Kim <js1304@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Minchan Kim <minchan@kernel.org>, Nitin Gupta <ngupta@vflare.org>,
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>,
Stephan Mueller <smueller@chronox.de>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>
Subject: Re: [PATCH v2 1/8] crypto: support (de)compression API that doesn't require tfm object
Date: Thu, 20 Aug 2015 14:47:28 +0800 [thread overview]
Message-ID: <20150820064728.GA26840@gondor.apana.org.au> (raw)
In-Reply-To: <1440052504-15442-2-git-send-email-iamjoonsoo.kim@lge.com>
On Thu, Aug 20, 2015 at 03:34:57PM +0900, Joonsoo Kim wrote:
> Until now, tfm object embeds (de)compression context in it and
> (de)compression in crypto API requires tfm object to use
> this context. But, there are some algorithms that doesn't need
> such context to operate. Therefore, this patch introduce new crypto
> compression API that call (de)compression function via crypto_alg,
> instead of tfm object. crypto_alg is required to get appropriate
> (de)compression function pointer. This can reduce overhead of
> maintaining multiple tfm if (de)compression doesn't require
> any context to operate.
>
> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
This isn't going to fly I'm afraid. The main purpose of a tfm
is not to allocate memory but to track the crypto_alg object
which could be a hardware device.
So you're not going to get away with not allocating it.
What you can do for these contextless algorithms (and by definition
every compression algorithm is conxteless) is to allocate a system-
wide tfm that is used by everybody, or at least by every one within
your subsystem.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
next prev parent reply other threads:[~2015-08-20 6:47 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-20 6:34 [PATCH v2 0/8] zram: introduce crypto compress noctx API and use it on zram Joonsoo Kim
2015-08-20 6:34 ` [PATCH v2 1/8] crypto: support (de)compression API that doesn't require tfm object Joonsoo Kim
2015-08-20 6:47 ` Herbert Xu [this message]
2015-08-20 7:52 ` Joonsoo Kim
2015-08-20 7:50 ` Herbert Xu
2015-08-20 8:05 ` Joonsoo Kim
2015-08-20 6:34 ` [PATCH v2 2/8] crypto/lzo: support decompress_noctx Joonsoo Kim
2015-08-27 1:54 ` Sergey Senozhatsky
2015-08-20 6:34 ` [PATCH v2 3/8] crypyo/lz4: " Joonsoo Kim
2015-08-27 1:56 ` Sergey Senozhatsky
2015-08-20 6:35 ` [PATCH v2 4/8] crypto/lz4hc: " Joonsoo Kim
2015-08-27 1:57 ` Sergey Senozhatsky
2015-08-20 6:35 ` [PATCH v2 5/8] crypto/842: " Joonsoo Kim
2015-08-20 6:35 ` [PATCH v2 6/8] zram: change zcomp_compress interface Joonsoo Kim
2015-08-27 2:14 ` Sergey Senozhatsky
2015-08-20 6:35 ` [PATCH v2 7/8] zram: use crypto API for compression Joonsoo Kim
2015-08-27 4:01 ` Sergey Senozhatsky
2015-08-28 12:02 ` [PATCH 0/2] prepare zram for crypto api-powered zcomp Sergey Senozhatsky
2015-08-28 12:02 ` [PATCH 1/2] zram: make stream find and release functions static Sergey Senozhatsky
2015-08-28 12:02 ` [PATCH 2/2] zram: pass zstrm down to decompression path Sergey Senozhatsky
2015-09-01 1:22 ` [PATCH 0/2] prepare zram for crypto api-powered zcomp Minchan Kim
2015-09-01 1:41 ` Sergey Senozhatsky
2015-09-01 2:06 ` Minchan Kim
2015-09-01 2:12 ` Sergey Senozhatsky
2015-09-07 5:32 ` Joonsoo Kim
2015-08-20 6:35 ` [PATCH v2 8/8] zram: use decompress_noctx Joonsoo Kim
2015-08-27 4:07 ` Sergey Senozhatsky
2015-08-27 5:47 ` Sergey Senozhatsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150820064728.GA26840@gondor.apana.org.au \
--to=herbert@gondor.apana.org.au \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=iamjoonsoo.kim@lge.com \
--cc=js1304@gmail.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=minchan@kernel.org \
--cc=ngupta@vflare.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=smueller@chronox.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).