archive mirror
 help / color / mirror / Atom feed
From: "Ondrej Mosnáček" <>
To: Eric Biggers <>
Cc: Herbert Xu <>,,,
	Mike Snitzer <>,
	Milan Broz <>,
	Mikulas Patocka <>,
	Binoy Jayan <>
Subject: Re: [RFC PATCH 5/6] crypto: aesni-intel - Add bulk request support
Date: Fri, 13 Jan 2017 12:27:28 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20170113031933.GA4956@zzz>

Hi Eric,

2017-01-13 4:19 GMT+01:00 Eric Biggers <>:
> To what extent does the performance benefit of this patchset result from just
> the reduced numbers of calls to kernel_fpu_begin() and kernel_fpu_end()?
> If it's most of the benefit, would it make any sense to optimize
> kernel_fpu_begin() and kernel_fpu_end() instead?
> And if there are other examples besides kernel_fpu_begin/kernel_fpu_end where
> the bulk API would provide a significant performance boost, can you mention
> them?

In the case of AES-NI ciphers, this is the only benefit. However, this
change is not intended solely (or primarily) for AES-NI ciphers, but
also for other drivers that have a high per-request overhead.

This patchset is in fact a reaction to Binoy Jayan's efforts (see
[1]). The problem with small requests to HW crypto drivers comes up
for example in Qualcomm's Android [2], where they actually hacked
together their own version of dm-crypt (called 'dm-req-crypt'), which
in turn used a driver-specific crypto mode, which does the IV
generation on its own, and thereby is able to process several sectors
at once. The goal is to extend the crypto API so that vendors don't
have to roll out their own workarounds to have efficient disk

> Interestingly, the arm64 equivalent to kernel_fpu_begin()
> (kernel_neon_begin_partial() in arch/arm64/kernel/fpsimd.c) appears to have an
> optimization where the SIMD registers aren't saved if they were already saved.
> I wonder why something similar isn't done on x86.

AFAIK, there can't be done much about the kernel_fpu_* functions, see e.g. [3].



> Eric

  reply	other threads:[~2017-01-13 11:27 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-12 12:59 [RFC PATCH 0/6] Add bulk skcipher requests to crypto API and dm-crypt Ondrej Mosnacek
2017-01-12 12:59 ` [RFC PATCH 1/6] crypto: skcipher - Add bulk request processing API Ondrej Mosnacek
2017-01-12 12:59 ` [RFC PATCH 2/6] crypto: skcipher - Add bulk request support to walk Ondrej Mosnacek
2017-01-12 12:59 ` [RFC PATCH 3/6] crypto: cryptd - Add skcipher bulk request support Ondrej Mosnacek
2017-01-12 12:59 ` [RFC PATCH 4/6] crypto: simd - Add " Ondrej Mosnacek
2017-01-12 12:59 ` [RFC PATCH 5/6] crypto: aesni-intel " Ondrej Mosnacek
2017-01-13  3:19   ` Eric Biggers
2017-01-13 11:27     ` Ondrej Mosnáček [this message]
2017-01-12 12:59 ` [RFC PATCH 6/6] dm-crypt: Add bulk crypto processing support Ondrej Mosnacek
2017-01-16  8:37   ` Binoy Jayan
2017-01-17 11:15     ` Ondrej Mosnáček
2017-01-13 10:41 ` [RFC PATCH 0/6] Add bulk skcipher requests to crypto API and dm-crypt Herbert Xu
2017-01-13 12:01   ` Ondrej Mosnáček
2017-01-13 14:29     ` Herbert Xu
2017-01-17 11:20       ` Ondrej Mosnáček
2017-01-18  4:48         ` Herbert Xu
2017-01-19 14:21           ` Ondrej Mosnáček
2017-01-23 13:04             ` Herbert Xu
2017-01-18 17:09     ` Binoy Jayan

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \

* 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).