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 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.) > 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. Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
