On Thu, Jan 27, 2022 at 04:44:48PM +1100, Herbert Xu wrote: > On Thu, Jan 27, 2022 at 04:40:16PM +1100, Herbert Xu wrote: > > > > The question is is it performance-critical? Including it as a > > parameter would be worthwhile if it is. But if its cost is dwarfed > > by that of the accompanying operations then it might not be worth > > the complexity. > > It looks like this is similar to the situation in XTS where I chose > not to make it a full parameter during the skcipher conversion: > > commit f1c131b45410a202eb45cc55980a7a9e4e4b4f40 > Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> > Date: Tue Nov 22 20:08:19 2016 +0800 > > crypto: xts - Convert to skcipher > > Cheers, Sure, that makes sense. Note that if the meaning of the first parameter to the template will differ (blockcipher_name vs. xctr_name), the full syntax probably should be supported by a separate template called "hctr2_base" rather than by "hctr2", to avoid having the meaning of the first parameter be context-dependent. This would be like gcm and gcm_base. So we'd have e.g.: hctr2(aes) hctr2_base(xctr-aes-aesni,polyval-pclmulqdqni) cra_name would be set to the former, while cra_driver_name would be set to the latter. - Eric
