On 18 April 2016 at 16:04, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > 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? As I know, now cbc engine also need to handle requests sector by sector, but for xts/ecb engine can support bulk block, which means can merge requests. > >> > 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. It will not broke it up, and it will check if the requests coming from dm-crypt can be merged together. > > If the data can be merged then it should have stayed as one piece > rather than being fragmented. Yes, usually one whole block can be merged into one request as the latency. > > Cheers, > -- > Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- Baolin.wang Best Regards -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
