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
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?
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.
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).
As per my understanding, AES-NI is not supported on arm based chipset.
Thanks,
Thanks,
Dinesh
On Mon, Jan 21, 2013 at 11:24 PM, Milan Broz <gmazyland@xxxxxxxxx> wrote:
On 01/22/2013 07:04 AM, Dinesh Garg wrote:Sorry, but fixing hw accelerator issues in sw is not reason for me.
> I want to use hardware based crypto engine which would provide better
> encryption/decryption throughput when packet sizes are bigger. If we
> invoke hardware based crypto engine for every 512 bytes, there is so
> much time spent in setting up cipher context in that throughput
> becomes very less.
But anyway, if you search archive (just one month ago) I replied
here mentioning the real problem with such change
http://www.saout.de/pipermail/dm-crypt/2012-December/002917.html
The real problem with allowing larger sector sizes is not in patch
(it is quite simple in fact) but in incompatibility it causes
(DM operates on 512 sector block level, LUKS metadata is not ready
for this etc.)
I still think that proper crypto hw accelerator should work even
with these small blocks (scatter-gather lists to offload multiple
buffers and operate in batch mode or whatever. If re-setting IV
for crypto context eat so much time, something is wrong).
Kernel crypto API provides api for async crypto drivers already.
But my reply still applies - it is on TODO list but I would like
to see some real world example, where we really need this.
(Like some on-disk encryption format which require such operation
and we would like to have support for it in Linux.)
For your particular machine. Try some new with AES-NI for example.
> Thats why I was thinking if I can contribute to dm-crypt where it can
> accept larger packet sizes, it would be great for hardware based
> crypto engine solution.
>
> HW based crypto engine outperforms the SW based when packet size
> reaches 8K.
I have years old board, where VIA padlock crypto hw acceleration
outperforms sw as well - with 512bytes block size.
Milan
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
