On 01/22/2013 09:00 AM, Dinesh Garg wrote: > I think HW accelerator is an issue with smaller packet size because: > 1. It takes time to switch the context from software to hardware ( i.e. interrupt handling) > 2. HW accelerators dont allow multiple crypto operations at the same time due to security reasons I think all these problems are technically solvable but that's not discussion for dmcrypt list... > What do you mean by DM operates at 512B level? Is it that DM always > calls dmcrypt with 512B data even if file system is 4K block size? Everything in block layer is calculated in sectors of 512 bytes size, just for bigger sector size proper alignment is required. (So if we support, say 8k block, we must _force_ all layers to use only 8k block. Otherwise you will get data corruption.) > I tried aggregating scatter gather list at the crypto driver layer > but it did not work because DM supposedly operates at 512B. Sending > multiple encryptions commands to HW CE does not help due to CE setup > time etc. As I said above, you have force DM/block layer to accept only properly sized requests. Otherwise I do not see problem in crypto layer. (This should be simulated with kernel cryptd() driver even without proper crypto hw, just it need some hacking.) > dm-crypt is excellent block driver encryption solution. If anyone can > guide me, I would like to contribute as this is problem faced by HW > accelerator( I read several mails in the archive). Please can you be more specific? Which HW accelerator you are using, where is the source of it and when it will be part of upstream kernel? (if not already). But as I said, the patch for dmcrypt is not complicated, it is incompatibility later which this can cause. So I would really like to see strong reason before we implement direct support for larger sectors. > As per my understanding, AES-NI is not supported on arm based > chipset. Sure, that was just an example. But I am sure that even on ARM you can do hw acceleration which works with 512 bytes sectors. Even if we provide option to use bigger block size, it will not be compatible with LUKS devices and other encryption schemes (like TrueCrypt) which use 512 block always. Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
