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 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
