[dm-crypt] Encrypting with larger packet size
dinesh.garg at gmail.com
Tue Jan 22 09:00:14 CET 2013
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.
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.
On Mon, Jan 21, 2013 at 11:24 PM, Milan Broz <gmazyland at gmail.com> wrote:
> On 01/22/2013 07:04 AM, Dinesh Garg wrote:
> > 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.
> Sorry, but fixing hw accelerator issues in sw is not reason for me.
> But anyway, if you search archive (just one month ago) I replied
> here mentioning the real problem with such change
> 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.)
> > 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.
> For your particular machine. Try some new with AES-NI for example.
> I have years old board, where VIA padlock crypto hw acceleration
> outperforms sw as well - with 512bytes block size.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dm-crypt