All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthias-Christian Ott <ott@mirix.org>
To: linux-crypto@vger.kernel.org
Subject: Re: Hardware acceleration indication in af_alg
Date: Fri, 21 Oct 2011 16:34:15 +0200	[thread overview]
Message-ID: <20111021143415.GE2050@qp> (raw)
In-Reply-To: <20111021141541.GC2050@qp>

On Fri, Oct 21, 2011 at 04:15:41PM +0200, Matthias-Christian Ott wrote:
> On Fri, Oct 21, 2011 at 03:23:36PM +0200, Herbert Xu wrote:
> > Matthias-Christian Ott <ott@mirix.org> wrote:
> > > I did some experiments with af_alg and noticed that to be really
> > > useful, it should indicate whether a certain algorithm is hardware
> > > accelerated. I guess this has to be inferred by the priority of the
> > > algorithm could be made available via a read-only socket option. Any
> > > thoughts on this?
> > > 
> > > I can imagine, an alternative approach and perhaps better approach
> > > would be to measure the speed of the kernel provided algorithm against
> > > a software implementation, but there are many other factors that could
> > > influence the results. Therefore, it is perhaps better to just make
> > > the assumption that hardware acceleration is faster which is made in
> > > the kernel anyhow.
> > 
> > You have to be careful to distinguish between hardware acceleration
> > that is directly available to user-space (such as AESNI) and those
> > that aren't.
> > 
> > For the former it makes zero sense to go through the kernel as
> > you'll only make it slower.  The latter case is the reason why
> > this interface exists.
> 
> This is why I didn't consider hardware acceleration that is directly
> available to user-space in the first place (I'm not aware of anything
> except CPUs that is usable this way). So the question remains whether
> e.g. the AES implementation provided through af_alg by the kernel is
> faster (and thus most likely hardware accelerated) than a software
> implementation. Since the kernel seems to make the assumption that
> hardware acceleration is faster, I asked whether it would be possible to
> pass this information to user-space as well.

Ignore that e-mail. The the recent user configuration patches
by Stefan Klassert seem to expose the algorithm's priority via
CRYPTOCFGA_PRIORITY_VAL. This should solve my problem, provided that
the patches will be included.

Regards,
Matthias-Christian

  reply	other threads:[~2011-10-21 14:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-18 13:13 Hardware acceleration indication in af_alg Matthias-Christian Ott
2011-10-21 13:23 ` Herbert Xu
2011-10-21 14:15   ` Matthias-Christian Ott
2011-10-21 14:34     ` Matthias-Christian Ott [this message]
2011-10-28 16:24   ` Nikos Mavrogiannopoulos
2011-11-01 12:43     ` Nikos Mavrogiannopoulos
2011-11-01 12:59       ` Jamie Iles
2011-11-02  2:11         ` Nikos Mavrogiannopoulos
2011-11-02 22:51         ` Herbert Xu

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=20111021143415.GE2050@qp \
    --to=ott@mirix.org \
    --cc=linux-crypto@vger.kernel.org \
    /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.