Re: OCF or Acrypto for IPSec and dm-crypt
On Mon, Sep 05, 2005 at 09:14:21AM +0300, Ronen Shitrit wrote:
>
> When is this Async Crypto API, going to be ready??
> Since I'm planning to take a full month vacation, by the end of this
> week,
> and if by the time I will be back, this Async Crypto APIs will be ready,
> and
> _part_of_the_mainline_, then I will need to re-evaluate my decision for
> going with
> the OCF, since the "big guys here likes to go with the mainline".
Unfortunately I can't give any guarantees of when it'll be ready.
However, you could most certainly speed up the process by helping
implementing any of the following steps:
: 1) Add support for multiple implementations for the same algorithm.
:
: For example, this lets you have both aes/aes-i586/aes-via_padlock
: registered and the one with the highest priority will be used.
: The priority will be set by the module with an override option
: for the user.
:
: 2) Extend the interface between crypto API and the underlying
: implementations to use scatterlists.
:
: Wrappers will be provided to extend implementations with existing
: single-block interfaces to provide scatterlists. Essentially
: it'll be the same as the current scatterlist walking function,
: albeit executed conceptually at a lower layer.
:
: 3) Add support for (raw, as in no scheduler/fail-over) async
: implementations through the addition of a callback function
: to crypto_tfm and a callback data argument to the existing
: top-level crypto entry point functions (encrypt/decrypt/etc).
:
: 4) Implement implementation registration notification.
:
: 5) Implement at least one scheduler using the same scatterlist
: interface used by async drivers and software implementations.
:
: It'll work in the manner which I described previously. For
: this particular scheduler, there will be one instantiation
: that listens for the registration events of underlying
: implementations and then reconfigures itself appropriately.
: For example, it could simply utilise the hard-coded method
: used by OpenBSD.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Two
Hi I have 2 enhancement suggestions, for the OCF: 1. As I mentioned in the OCF dm-crypt patch, it will be very nice, if the OCF will support symmetric encryption when the source buffer is different then the destination buffer. 2. Currently the OCF support 3 types of buffers: SKB, UIO and contiguous buffers, it will be very nice, if the OCF will also support scatter list. Regards Ronen Shitrit Marvell Semiconductor Israel Ltd - To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Dm-crypt patch for OCF
Hi all Attached is a patch for the dm_crypt HD encryption which use the OCF. The patch includes a new Kconfig configuration option for OCF_DM_CRYPT, When choosing this option the dm_crypt will use the OCF for dm_crypt sector encryption/decryption, When using the essiv mode, the essiv generation will use the kernel cryptoAPIs. Currently this patch support the following encryption algorithms: DES-CBC, 3DES-CBC and AES-CBC. I tested this driver using AES-CBC, with OCF SW driver, it seems stable. I used the Bonnie benchmark to get some statistics: http://www.textuality.com/bonnie/ The bandwidth performance are much better when using the OCF dm_crypt. This might be explained since Bonnie is using a large blocks of io (crypt_convert get contexts of 512byte * 256), which cause the dm_crypt to Q few requests at a time, and this "multi tasking", cause that the HD and the CPU "bandwidth" are exploit in a better way. (I assume) When using mkfs.ext2 on large partition I see that the OCF dm_crypt requires about 7% more time then when using the standard dm_crypt. This can be explained since the mkfs.ext2 is mostly using writes of small blocks (crypt_convert get contexts of 512byte * 8), Which cause that we gets less "multi tasking", and as explained below the write request are not optimized in this patch. Currently the dm_crypt is implemented in a way that: for decryption (read requests), it is using the source buffer itself, While for the encryption (write requests), it is using a different buffer. The current implementation of the OCF only support encryption on the source buffer, which is not efficient for this case, therefore this patch has overhead of copying the buffers to be encrypted. Thanks to Evgeniy Polyakov for the Acrypto patch reference. Regards Ronen Shitrit Marvell Semiconductor Israel Ltd ocf_dm_crypt.patch Description: ocf_dm_crypt.patch
