On Fri, Feb 07, 2014 at 08:30:26AM +0100, Ard Biesheuvel wrote: > > I agree that it would be trivial for cbc(%s) to probe for ecb(%s) > before settling on using plain '%s. > But how to probe for an /accelerated/ ecb(%s), i.e., how to avoid > using the generic ecb(%s) which adds nothing but overhead? > The other issue is how to find out what the optimal chunk size is for > the accelerated ecb(%s) implementation, which would involve adding a > struct member that holds the preferred number of blocks presented in a > single invocation. > In fact, that would solve both issues, as the probe could check this > struct member for a >1 value (as my current series does but in against > a cipher_alg instance) I'd like to see some numbers on the actual overhead of ecb before we get too deeply into optimising it away. In any case, one easy solution is to change the driver name of generic ecb to ecb_generic (cf. ccm.c) which you could then check for in cbc and elsewhere. Also, how are you determining the optimal number of blocks? For the in-place case you're bound by how much memory you can find for the temporary buffer. For the not-in-place case wouldn't you just go for as much as you can? Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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
