[dm-crypt] Encrypting with larger packet size
gmazyland at gmail.com
Tue Jan 22 08:24:31 CET 2013
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.
More information about the dm-crypt