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.
Regards,
Matthias-Christian
Matthias-Christian Ott <[email protected]> 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.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Fri, Oct 21, 2011 at 03:23:36PM +0200, Herbert Xu wrote:
> Matthias-Christian Ott <[email protected]> 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.
Regards,
Matthias-Christian
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 <[email protected]> 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
On 10/21/2011 03:23 PM, Herbert Xu wrote:
> Matthias-Christian Ott <[email protected]> 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.
How can this be done? The only driver field that could be used for that
is cra_priority and it seems it typically set to 300 irrespective of
instruction based crypto or external device.
regards,
Nikos
On 10/28/2011 06:24 PM, Nikos Mavrogiannopoulos wrote:
>>> 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.
> How can this be done? The only driver field that could be used for
> that is cra_priority and it seems it typically set to 300
> irrespective of instruction based crypto or external device.
I suppose that no answer means there is no way. In that case would you
consider this or a similar patch to indicate whether a driver provides
an algorithm not available to userspace via other means (e.g.
instruction set)? This would allow users of the kernel interfaces to
avoid using software implementations or implementations that are
available to userspace anyway.
regards,
Nikos
Hi Nikos,
On Tue, Nov 01, 2011 at 01:43:26PM +0100, Nikos Mavrogiannopoulos wrote:
> On 10/28/2011 06:24 PM, Nikos Mavrogiannopoulos wrote:
>
> >>> 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.
> > How can this be done? The only driver field that could be used for
> > that is cra_priority and it seems it typically set to 300
> > irrespective of instruction based crypto or external device.
>
> I suppose that no answer means there is no way. In that case would you
> consider this or a similar patch to indicate whether a driver provides
> an algorithm not available to userspace via other means (e.g.
> instruction set)? This would allow users of the kernel interfaces to
> avoid using software implementations or implementations that are
> available to userspace anyway.
[...]
> diff --git a/include/linux/crypto.h b/include/linux/crypto.h
> index de9adec..3e14cee 100644
> --- a/include/linux/crypto.h
> +++ b/include/linux/crypto.h
> @@ -51,6 +51,11 @@
> #define CRYPTO_ALG_DYING 0x00000040
> #define CRYPTO_ALG_ASYNC 0x00000080
>
> +/* Set this bit if the algorithm provided is hardware accelerated but
> + * not available to userspace via instruction set or so.
> + */
> +#define CRYPTO_ALG_KERN_ONLY 0x00000100
Would it be a bit clearer if this was CRYPTO_ALG_IS_UNPRIVILIGED and was
set the other way round (so instruction set based ones that users can
use)? I had to do a double take with KERN_ONLY.
Jamie
On 11/01/2011 01:59 PM, Jamie Iles wrote:
> Hi Nikos,
>
> On Tue, Nov 01, 2011 at 01:43:26PM +0100, Nikos Mavrogiannopoulos wrote:
[...]
>> I suppose that no answer means there is no way. In that case would you
>> consider this or a similar patch to indicate whether a driver provides
>> an algorithm not available to userspace via other means (e.g.
>> instruction set)? This would allow users of the kernel interfaces to
>> avoid using software implementations or implementations that are
>> available to userspace anyway.
> [...]
>> diff --git a/include/linux/crypto.h b/include/linux/crypto.h
>> index de9adec..3e14cee 100644
>> --- a/include/linux/crypto.h
>> +++ b/include/linux/crypto.h
>> @@ -51,6 +51,11 @@
>> #define CRYPTO_ALG_DYING 0x00000040
>> #define CRYPTO_ALG_ASYNC 0x00000080
>>
>> +/* Set this bit if the algorithm provided is hardware accelerated but
>> + * not available to userspace via instruction set or so.
>> + */
>> +#define CRYPTO_ALG_KERN_ONLY 0x00000100
> Would it be a bit clearer if this was CRYPTO_ALG_IS_UNPRIVILIGED and was
> set the other way round (so instruction set based ones that users can
> use)? I had to do a double take with KERN_ONLY.
Could also be, although I think both names are not so intuitive :) Note
btw that the flag value in the patch is not correct (it overlaps with
another one).
regards,
Nikos
Jamie Iles <[email protected]> wrote:
>
>> diff --git a/include/linux/crypto.h b/include/linux/crypto.h
>> index de9adec..3e14cee 100644
>> --- a/include/linux/crypto.h
>> +++ b/include/linux/crypto.h
>> @@ -51,6 +51,11 @@
>> #define CRYPTO_ALG_DYING 0x00000040
>> #define CRYPTO_ALG_ASYNC 0x00000080
>>
>> +/* Set this bit if the algorithm provided is hardware accelerated but
>> + * not available to userspace via instruction set or so.
>> + */
>> +#define CRYPTO_ALG_KERN_ONLY 0x00000100
>
> Would it be a bit clearer if this was CRYPTO_ALG_IS_UNPRIVILIGED and was
> set the other way round (so instruction set based ones that users can
> use)? I had to do a double take with KERN_ONLY.
Actually I think Nikos's suggestion is the right one. Going the
other way would be more intrusive. Of course I'm open to a better
name than KERN_ONLY.
Thanks!
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt