On Mon, Apr 18, 2016 at 03:58:59PM +0800, Baolin Wang wrote: > > That depends on the hardware engine. Some cipher hardware engines > (like xts(aes) engine) can handle the intermediate values (IV) by > themselves in one bulk block, which means we can increase the size of > the request by merging request rather than always 512 bytes and thus > increase the hardware engine processing speed. But for some other > hardware engines (like cbc(aes) engine), they can not support bulk > block, must sector by sector. So the engine drivers can select the > suitable mode to do encryption/decryption. So what is this supposed to handle, xts or cbc? > > Even with batching we should be involving the user because only the > > user knows (if anyone does) whether more data will be forthcoming. > > If this cipher engine can support bulk block encryption, the crypto > engine framework can merge requests if they are eligible > automatically. Don't need to worry about how many data will be > forthcoming. Merging is simply wrong when the data is coming in as one piece and you've just artifically broken it up, only to merge it later. If the data can be merged then it should have stayed as one piece rather than being fragmented. 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
