From: Tadeusz Struk <tadeusz.struk@intel.com>
To: Herbert Xu <herbert@gondor.apana.org.au>,
Tadeusz Struk <tstruk@gmail.com>
Cc: Stephan Mueller <smueller@chronox.de>,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org
Subject: Re: [PATCH] crypto: af_alg - add async support to algif_aead
Date: Wed, 20 Jan 2016 12:18:24 -0800 [thread overview]
Message-ID: <569FEB90.5020203@intel.com> (raw)
In-Reply-To: <20160119003428.GA5571@gondor.apana.org.au>
Hi Herbert,
On 01/18/2016 04:34 PM, Herbert Xu wrote:
>> My understanding is that the sock_kmalloc is mainly used for allocations
>> > of the user provided data, because it keeps tracks of how much memory
>> > is allocated by a socket, and makes sure that is will not exceed the
>> > sysctl_optmem_max limit. Usually the internal structures, with fixed
>> > size are allocated simply with kmalloc. I don't think that using
>> > sock_kmalloc will give us any benefit here.
> If there is only ever one of them per-socket then kmalloc is fine,
> otherwise you should use sock_kmalloc.
>
I tried sock_kmalloc and it will not work. The sysctl_optmem_max by
default is 20480 bytes. The aead ctx by itself takes more than half of
it (11832 bytes). A single async request takes 11408 bytes.
It means we need to use kmalloc or no async request could be allocated.
I would opt to go with this version and I'll convert both algif_aead
and algif_skcipher to use sock_hold later.
Thanks,
--
TS
next prev parent reply other threads:[~2016-01-20 20:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-15 19:21 [PATCH] crypto: af_alg - add async support to algif_aead Tadeusz Struk
2016-01-17 15:07 ` Stephan Mueller
2016-01-18 15:22 ` Tadeusz Struk
2016-01-19 0:34 ` Herbert Xu
2016-01-19 15:18 ` Tadeusz Struk
2016-01-20 20:18 ` Tadeusz Struk [this message]
2016-01-21 5:00 ` Herbert Xu
-- strict thread matches above, loose matches on Subject: below --
2016-01-27 22:10 Tadeusz Struk
2016-01-27 22:29 ` kbuild test robot
2016-01-27 22:41 ` Tadeusz Struk
2016-01-28 6:26 ` Stephan Mueller
2016-01-28 16:00 ` Tadeusz Struk
2016-01-28 17:09 ` Stephan Mueller
2016-01-28 17:30 ` Tadeusz Struk
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=569FEB90.5020203@intel.com \
--to=tadeusz.struk@intel.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=smueller@chronox.de \
--cc=tstruk@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.