RE: Dm-crypt patch for OCF
I always assume that there won't be any errors ;) I fixed it, Thanks for the review. I even decide to be a little too cautious now, and in case r<0 the kcryptd_do_work task will go to sleep for 1/2 sec before freeing the io, to give the read requests a chance to finish (If there are any). See attached. Regards Ronen Shitrit Marvell Semiconductor Israel Ltd -Original Message- From: Evgeniy Polyakov [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 07, 2005 11:19 AM To: Ronen Shitrit Cc: [EMAIL PROTECTED]; linux-crypto@vger.kernel.org Subject: Re: Dm-crypt patch for OCF On Wed, Sep 07, 2005 at 11:07:14AM +0300, Ronen Shitrit ([EMAIL PROTECTED]) wrote: > I don't think so, > > In the kcrypt_do_work I call dec_pending only in case return value is > error. But you return from crypto code with zero (OK) status when crypto_dispatch() can fail, and this BIO will be lost. I was confused by error processing, so described problem in a wrong way first time, sorry. > Other from this for each context of convert_crypt which is might be > breaked into some sectors decryption requests, I will call the > dec_pending only in the last read callback of the last sector. > > -> I assume that the order of the insertion to the OCF Qs, is the > -> order > of the completion. > > If I'm wrong please point me in the code, sorry. > > Regards > > Ronen Shitrit > Marvell Semiconductor Israel Ltd > > > -Original Message- > From: Evgeniy Polyakov [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 07, 2005 10:57 AM > To: Ronen Shitrit > Cc: [EMAIL PROTECTED]; linux-crypto@vger.kernel.org > Subject: Re: Dm-crypt patch for OCF > > On Wed, Sep 07, 2005 at 10:44:01AM +0300, Ronen Shitrit > ([EMAIL PROTECTED]) wrote: > > Hi > > > > I don't think there is any problem to let the read request to flow > > through, since in the original code, In order to decrypt the read > > requests, we create a new task (workingQ) that perform the decrypt, > > and doesn't notify any other task when it finish, except for the > > dec_pending(io,r) which I moved to the read callback. > > No, dm-crypt only calls dec_pending() with BIO with decrypted data, > but with your code it can be called before read callback is invoked > and even before BIO is touched in crypto code. > > > Regards > > > > Ronen Shitrit > > Marvell Semiconductor Israel Ltd > > > > > > -Original Message- > > From: Evgeniy Polyakov [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, September 07, 2005 10:36 AM > > To: Ronen Shitrit > > Cc: [EMAIL PROTECTED]; linux-crypto@vger.kernel.org > > Subject: Re: Dm-crypt patch for OCF > > > > On Tue, Sep 06, 2005 at 09:20:42PM +0300, Ronen Shitrit > > ([EMAIL PROTECTED]) wrote: > > > Hi > > > > Hello, Ronen. > > I have some doubts - you only wait on write request, but allow read > > request to flow through - when doind read request it does not mean, > > that dm-crypt is the last target, it can be even freed when your > > read callback will be called. > > > > And according to crypto sessions - I was confused by this name, and > > did not understood you from the first point. > > I want to say, that acrypto does not have such crypto session like > > OCF > > > has. It only has crypto requests in OCF terminology, since it does > > not > > > require special controlling strucutre on top of it. > > I will describe it in more details in different thread. > > > > > I improved the first patch, see attached. > > > > > > Dm-crypt: > > > -)On the encrypt(write) side we first allocate a new buffer then > > > we encrypt (using crypt_convert) the src buffer to the new buffer, > > > we send it > > > to be written through the generic_make_request(clone), then when > > > the > > > clone->bi_end_io is called we free the buffer and the io. > > > -)On the decrypt(read) side we first read the buffer to the source > > > through the generic_make_request(clone), then when the > > clone->bi_end_io > > > is called, we create a new working thread which will decrypt > > > (using > > > crypt_convert) the buffer and free the io. > > > > > > In the first patch, for each crypt_convert operation we send all > > > the > > > > sectors of the context to be encrypt/decrypt to the OCF, and then > > > we > > > > are waiting for A completion of all of these sectors before > > > returning from crypt_convert, i.e. we get a limitation that only > > > one > > > > encrypt/decrypt crypt_convert operation can occur in parallel. > > > > > > In the attached new patch, I removed this limitation for the > > > decrypt(read) crypt_convert, > > > By doing this I can see that when running the Bonnie benchmark, I > > > get better performance for the read/rewrite tests. > > > > > > The same approach can be used for the encrypt(write) > > > crypt_convert, it > > > > > is a little bit more complicated then the decrypt(read), maybe I > > > will try to implement it in future patches. > > > > > > I also noticed that sometimes
Re: Dm-crypt patch for OCF
On Wed, Sep 07, 2005 at 11:07:14AM +0300, Ronen Shitrit ([EMAIL PROTECTED]) wrote: > I don't think so, > > In the kcrypt_do_work I call dec_pending only in case return value is > error. But you return from crypto code with zero (OK) status when crypto_dispatch() can fail, and this BIO will be lost. I was confused by error processing, so described problem in a wrong way first time, sorry. > Other from this for each context of convert_crypt which is might be > breaked into some sectors decryption requests, > I will call the dec_pending only in the last read callback of the last > sector. > > -> I assume that the order of the insertion to the OCF Qs, is the order > of the completion. > > If I'm wrong please point me in the code, sorry. > > Regards > > Ronen Shitrit > Marvell Semiconductor Israel Ltd > > > -Original Message- > From: Evgeniy Polyakov [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 07, 2005 10:57 AM > To: Ronen Shitrit > Cc: [EMAIL PROTECTED]; linux-crypto@vger.kernel.org > Subject: Re: Dm-crypt patch for OCF > > On Wed, Sep 07, 2005 at 10:44:01AM +0300, Ronen Shitrit > ([EMAIL PROTECTED]) wrote: > > Hi > > > > I don't think there is any problem to let the read request to flow > > through, since in the original code, In order to decrypt the read > > requests, we create a new task (workingQ) that perform the decrypt, > > and doesn't notify any other task when it finish, except for the > > dec_pending(io,r) which I moved to the read callback. > > No, dm-crypt only calls dec_pending() with BIO with decrypted data, but > with your code it can be called before read callback is invoked and even > before BIO is touched in crypto code. > > > Regards > > > > Ronen Shitrit > > Marvell Semiconductor Israel Ltd > > > > > > -Original Message- > > From: Evgeniy Polyakov [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, September 07, 2005 10:36 AM > > To: Ronen Shitrit > > Cc: [EMAIL PROTECTED]; linux-crypto@vger.kernel.org > > Subject: Re: Dm-crypt patch for OCF > > > > On Tue, Sep 06, 2005 at 09:20:42PM +0300, Ronen Shitrit > > ([EMAIL PROTECTED]) wrote: > > > Hi > > > > Hello, Ronen. > > I have some doubts - you only wait on write request, but allow read > > request to flow through - when doind read request it does not mean, > > that dm-crypt is the last target, it can be even freed when your read > > callback will be called. > > > > And according to crypto sessions - I was confused by this name, and > > did not understood you from the first point. > > I want to say, that acrypto does not have such crypto session like OCF > > > has. It only has crypto requests in OCF terminology, since it does not > > > require special controlling strucutre on top of it. > > I will describe it in more details in different thread. > > > > > I improved the first patch, see attached. > > > > > > Dm-crypt: > > > -)On the encrypt(write) side we first allocate a new buffer then we > > > encrypt (using crypt_convert) the src buffer to the new buffer, we > > > send it > > > to be written through the generic_make_request(clone), then when > > > the > > > clone->bi_end_io is called we free the buffer and the io. > > > -)On the decrypt(read) side we first read the buffer to the source > > > through the generic_make_request(clone), then when the > > clone->bi_end_io > > > is called, we create a new working thread which will decrypt > > > (using > > > crypt_convert) the buffer and free the io. > > > > > > In the first patch, for each crypt_convert operation we send all the > > > > sectors of the context to be encrypt/decrypt to the OCF, and then we > > > > are waiting for A completion of all of these sectors before > > > returning from crypt_convert, i.e. we get a limitation that only one > > > > encrypt/decrypt crypt_convert operation can occur in parallel. > > > > > > In the attached new patch, I removed this limitation for the > > > decrypt(read) crypt_convert, > > > By doing this I can see that when running the Bonnie benchmark, I > > > get better performance for the read/rewrite tests. > > > > > > The same approach can be used for the encrypt(write) crypt_convert, > > > it > > > > > is a little bit more complicated then the decrypt(read), maybe I > > > will try to implement it in future patches. > > > > > > I also noticed that sometimes I get 2 encrypt(write) crypt_convert > > > in parallel?!?!, that why I moved the wr_pending into a separate > > > structure, > > > > > > which is allocated per write request. > > > This change affected the write performance only in a bit, less then > > 1%. > > > > > > btw - this patch is a patch for kernel 2.6.12, with OCF 20050630 > > > patch > > > > > applied on it. > > > same tests were used as for the first patch. > > > > > > Regards > > > > > > Ronen Shitrit > > > Marvell Semiconductor Israel Ltd > > > > > > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL P
Re: Dm-crypt patch for OCF
On Wed, Sep 07, 2005 at 12:03:50PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> On Wed, Sep 07, 2005 at 11:57:08AM +0400, Evgeniy Polyakov ([EMAIL
> PROTECTED]) wrote:
> > On Wed, Sep 07, 2005 at 10:44:01AM +0300, Ronen Shitrit ([EMAIL PROTECTED])
> > wrote:
> > > Hi
> > >
> > > I don't think there is any problem to let the read request to flow
> > > through, since in the original code,
> > > In order to decrypt the read requests, we create a new task (workingQ)
> > > that perform the decrypt, and
> > > doesn't notify any other task when it finish, except for the
> > > dec_pending(io,r) which I moved to the read callback.
> >
> > No, dm-crypt only calls dec_pending() with BIO with decrypted data,
> > but with your code it can be called before read callback is invoked
> > and even before BIO is touched in crypto code.
>
> I mean following code:
+crp->crp_sid = cc->ocf_cryptoid;
+if(crypto_dispatch(crp) != 0) {
+ printk("dm_ocf_process: crypto_dispatch failed!!\n");
+ }
+
+ return 0;
+
+}
> +#if defined(CONFIG_OCF_DM_CRYPT)
> + r = ocf_crypt_convert(cc, &ctx, io);
> +
> + if(r < 0)
> + dec_pending(io, r);
> +#else
So it will process BIO as error, while crypto code did not even touch
it.
And btw, you do not check kmalloc() result in ocf_crypt_convert(),
you need __GFP_NOFAIL bit set to guarantee successfull allocation.
--
Evgeniy Polyakov
-
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
RE: Dm-crypt patch for OCF
I don't think so, In the kcrypt_do_work I call dec_pending only in case return value is error. Other from this for each context of convert_crypt which is might be breaked into some sectors decryption requests, I will call the dec_pending only in the last read callback of the last sector. -> I assume that the order of the insertion to the OCF Qs, is the order of the completion. If I'm wrong please point me in the code, sorry. Regards Ronen Shitrit Marvell Semiconductor Israel Ltd -Original Message- From: Evgeniy Polyakov [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 07, 2005 10:57 AM To: Ronen Shitrit Cc: [EMAIL PROTECTED]; linux-crypto@vger.kernel.org Subject: Re: Dm-crypt patch for OCF On Wed, Sep 07, 2005 at 10:44:01AM +0300, Ronen Shitrit ([EMAIL PROTECTED]) wrote: > Hi > > I don't think there is any problem to let the read request to flow > through, since in the original code, In order to decrypt the read > requests, we create a new task (workingQ) that perform the decrypt, > and doesn't notify any other task when it finish, except for the > dec_pending(io,r) which I moved to the read callback. No, dm-crypt only calls dec_pending() with BIO with decrypted data, but with your code it can be called before read callback is invoked and even before BIO is touched in crypto code. > Regards > > Ronen Shitrit > Marvell Semiconductor Israel Ltd > > > -Original Message- > From: Evgeniy Polyakov [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 07, 2005 10:36 AM > To: Ronen Shitrit > Cc: [EMAIL PROTECTED]; linux-crypto@vger.kernel.org > Subject: Re: Dm-crypt patch for OCF > > On Tue, Sep 06, 2005 at 09:20:42PM +0300, Ronen Shitrit > ([EMAIL PROTECTED]) wrote: > > Hi > > Hello, Ronen. > I have some doubts - you only wait on write request, but allow read > request to flow through - when doind read request it does not mean, > that dm-crypt is the last target, it can be even freed when your read > callback will be called. > > And according to crypto sessions - I was confused by this name, and > did not understood you from the first point. > I want to say, that acrypto does not have such crypto session like OCF > has. It only has crypto requests in OCF terminology, since it does not > require special controlling strucutre on top of it. > I will describe it in more details in different thread. > > > I improved the first patch, see attached. > > > > Dm-crypt: > > -)On the encrypt(write) side we first allocate a new buffer then we > > encrypt (using crypt_convert) the src buffer to the new buffer, we > > send it > > to be written through the generic_make_request(clone), then when > > the > > clone->bi_end_io is called we free the buffer and the io. > > -)On the decrypt(read) side we first read the buffer to the source > > through the generic_make_request(clone), then when the > clone->bi_end_io > > is called, we create a new working thread which will decrypt > > (using > > crypt_convert) the buffer and free the io. > > > > In the first patch, for each crypt_convert operation we send all the > > sectors of the context to be encrypt/decrypt to the OCF, and then we > > are waiting for A completion of all of these sectors before > > returning from crypt_convert, i.e. we get a limitation that only one > > encrypt/decrypt crypt_convert operation can occur in parallel. > > > > In the attached new patch, I removed this limitation for the > > decrypt(read) crypt_convert, > > By doing this I can see that when running the Bonnie benchmark, I > > get better performance for the read/rewrite tests. > > > > The same approach can be used for the encrypt(write) crypt_convert, > > it > > > is a little bit more complicated then the decrypt(read), maybe I > > will try to implement it in future patches. > > > > I also noticed that sometimes I get 2 encrypt(write) crypt_convert > > in parallel?!?!, that why I moved the wr_pending into a separate > > structure, > > > > which is allocated per write request. > > This change affected the write performance only in a bit, less then > 1%. > > > > btw - this patch is a patch for kernel 2.6.12, with OCF 20050630 > > patch > > > applied on it. > > same tests were used as for the first patch. > > > > Regards > > > > Ronen Shitrit > > Marvell Semiconductor Israel Ltd > > > > > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Ronen Shitrit > > Sent: Monday, September 05, 2005 6:33 PM > > To: [EMAIL PROTECTED]; linux-crypto@vger.kernel.org > > Cc: Evgeniy Polyakov; David McCullough > > Subject: 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 us
Re: Dm-crypt patch for OCF
On Wed, Sep 07, 2005 at 11:57:08AM +0400, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: > On Wed, Sep 07, 2005 at 10:44:01AM +0300, Ronen Shitrit ([EMAIL PROTECTED]) > wrote: > > Hi > > > > I don't think there is any problem to let the read request to flow > > through, since in the original code, > > In order to decrypt the read requests, we create a new task (workingQ) > > that perform the decrypt, and > > doesn't notify any other task when it finish, except for the > > dec_pending(io,r) which I moved to the read callback. > > No, dm-crypt only calls dec_pending() with BIO with decrypted data, > but with your code it can be called before read callback is invoked > and even before BIO is touched in crypto code. I mean following code: +#if defined(CONFIG_OCF_DM_CRYPT) + r = ocf_crypt_convert(cc, &ctx, io); + + if(r < 0) + dec_pending(io, r); +#else > > Regards > > > > Ronen Shitrit > > Marvell Semiconductor Israel Ltd > > > > > > -Original Message- > > From: Evgeniy Polyakov [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, September 07, 2005 10:36 AM > > To: Ronen Shitrit > > Cc: [EMAIL PROTECTED]; linux-crypto@vger.kernel.org > > Subject: Re: Dm-crypt patch for OCF > > > > On Tue, Sep 06, 2005 at 09:20:42PM +0300, Ronen Shitrit > > ([EMAIL PROTECTED]) wrote: > > > Hi > > > > Hello, Ronen. > > I have some doubts - you only wait on write request, but allow read > > request to flow through - when doind read request it does not mean, that > > dm-crypt is the last target, it can be even freed when your read > > callback will be called. > > > > And according to crypto sessions - I was confused by this name, and did > > not understood you from the first point. > > I want to say, that acrypto does not have such crypto session like OCF > > has. It only has crypto requests in OCF terminology, since it does not > > require special controlling strucutre on top of it. > > I will describe it in more details in different thread. > > > > > I improved the first patch, see attached. > > > > > > Dm-crypt: > > > -)On the encrypt(write) side we first allocate a new buffer then we > > > encrypt (using crypt_convert) the src buffer to the new buffer, we > > > send it > > > to be written through the generic_make_request(clone), then when the > > > clone->bi_end_io is called we free the buffer and the io. > > > -)On the decrypt(read) side we first read the buffer to the source > > > through the generic_make_request(clone), then when the > > clone->bi_end_io > > > is called, we create a new working thread which will decrypt (using > > > crypt_convert) the buffer and free the io. > > > > > > In the first patch, for each crypt_convert operation we send all the > > > sectors of the context to be encrypt/decrypt to the OCF, and then we > > > are waiting for A completion of all of these sectors before returning > > > from crypt_convert, i.e. we get a limitation that only one > > > encrypt/decrypt crypt_convert operation can occur in parallel. > > > > > > In the attached new patch, I removed this limitation for the > > > decrypt(read) crypt_convert, > > > By doing this I can see that when running the Bonnie benchmark, I get > > > better performance for the read/rewrite tests. > > > > > > The same approach can be used for the encrypt(write) crypt_convert, it > > > > > is a little bit more complicated then the decrypt(read), maybe I will > > > try to implement it in future patches. > > > > > > I also noticed that sometimes I get 2 encrypt(write) crypt_convert in > > > parallel?!?!, that why I moved the wr_pending into a separate > > > structure, > > > > > > which is allocated per write request. > > > This change affected the write performance only in a bit, less then > > 1%. > > > > > > btw - this patch is a patch for kernel 2.6.12, with OCF 20050630 patch > > > > > applied on it. > > > same tests were used as for the first patch. > > > > > > Regards > > > > > > Ronen Shitrit > > > Marvell Semiconductor Israel Ltd > > > > > > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of Ronen Shitrit > > > Sent: Monday, September 05, 2005 6:33 PM > > > To: [EMAIL PROTECTED]; linux-crypto@vger.kernel.org > > > Cc: Evgeniy Polyakov; David McCullough > > > Subject: 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
Re: Dm-crypt patch for OCF
On Wed, Sep 07, 2005 at 10:44:01AM +0300, Ronen Shitrit ([EMAIL PROTECTED]) wrote: > Hi > > I don't think there is any problem to let the read request to flow > through, since in the original code, > In order to decrypt the read requests, we create a new task (workingQ) > that perform the decrypt, and > doesn't notify any other task when it finish, except for the > dec_pending(io,r) which I moved to the read callback. No, dm-crypt only calls dec_pending() with BIO with decrypted data, but with your code it can be called before read callback is invoked and even before BIO is touched in crypto code. > Regards > > Ronen Shitrit > Marvell Semiconductor Israel Ltd > > > -Original Message- > From: Evgeniy Polyakov [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 07, 2005 10:36 AM > To: Ronen Shitrit > Cc: [EMAIL PROTECTED]; linux-crypto@vger.kernel.org > Subject: Re: Dm-crypt patch for OCF > > On Tue, Sep 06, 2005 at 09:20:42PM +0300, Ronen Shitrit > ([EMAIL PROTECTED]) wrote: > > Hi > > Hello, Ronen. > I have some doubts - you only wait on write request, but allow read > request to flow through - when doind read request it does not mean, that > dm-crypt is the last target, it can be even freed when your read > callback will be called. > > And according to crypto sessions - I was confused by this name, and did > not understood you from the first point. > I want to say, that acrypto does not have such crypto session like OCF > has. It only has crypto requests in OCF terminology, since it does not > require special controlling strucutre on top of it. > I will describe it in more details in different thread. > > > I improved the first patch, see attached. > > > > Dm-crypt: > > -)On the encrypt(write) side we first allocate a new buffer then we > > encrypt (using crypt_convert) the src buffer to the new buffer, we > > send it > > to be written through the generic_make_request(clone), then when the > > clone->bi_end_io is called we free the buffer and the io. > > -)On the decrypt(read) side we first read the buffer to the source > > through the generic_make_request(clone), then when the > clone->bi_end_io > > is called, we create a new working thread which will decrypt (using > > crypt_convert) the buffer and free the io. > > > > In the first patch, for each crypt_convert operation we send all the > > sectors of the context to be encrypt/decrypt to the OCF, and then we > > are waiting for A completion of all of these sectors before returning > > from crypt_convert, i.e. we get a limitation that only one > > encrypt/decrypt crypt_convert operation can occur in parallel. > > > > In the attached new patch, I removed this limitation for the > > decrypt(read) crypt_convert, > > By doing this I can see that when running the Bonnie benchmark, I get > > better performance for the read/rewrite tests. > > > > The same approach can be used for the encrypt(write) crypt_convert, it > > > is a little bit more complicated then the decrypt(read), maybe I will > > try to implement it in future patches. > > > > I also noticed that sometimes I get 2 encrypt(write) crypt_convert in > > parallel?!?!, that why I moved the wr_pending into a separate > > structure, > > > > which is allocated per write request. > > This change affected the write performance only in a bit, less then > 1%. > > > > btw - this patch is a patch for kernel 2.6.12, with OCF 20050630 patch > > > applied on it. > > same tests were used as for the first patch. > > > > Regards > > > > Ronen Shitrit > > Marvell Semiconductor Israel Ltd > > > > > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Ronen Shitrit > > Sent: Monday, September 05, 2005 6:33 PM > > To: [EMAIL PROTECTED]; linux-crypto@vger.kernel.org > > Cc: Evgeniy Polyakov; David McCullough > > Subject: 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 t
Re: OCF or Acrypto for IPSec and dm-crypt
On Mon, Sep 05, 2005 at 12:38:33PM +1000, Herbert Xu ([EMAIL PROTECTED]) wrote:
> Ronen Shitrit <[EMAIL PROTECTED]> wrote:
> >
> > I think, Correct me if I'm wrong,
> > What you described below, is 1 session with few operations (using the
> > routing feature of the acrypto), but once the session/set of operations
> > are done, then the session is closed.
>
> I see. You want the session to last through the lifetime of an IPsec
> SA, right?
>
> Well the good news is that the Async Crypto API that I'm working on
> will do exactly that. The session is identified with the existing
> crypto_tfm object which is tied to each IPsec SA (for IPsec that is).
I was confused by your terminology :)
Crypto session in acrypto is only structure, which contains
src/dst/operation and some other parameters needed to properly process
data. Each crypto layer does have it - OCF has crypto request, sync
crypto has all that data as function parameters.
Acrypto does not require additional "main" crypto session under which
all crypto operations are performed, like crypto session in OCF or TFM
in sync crypto, in this regard acrypto is fully asynchronous since each
crypto request can belong to any crypto device, can be moved between
them and so on, like OCF allows too, it just does not require
some controlling stuff on top of it due to stack design.
According to one session per SA.
Sync crypto already has it - it stores all it's data in TFM or provide
it as function parameters, when such approach is going to be used for
some advanced management like fallback from device to device or request
batching, it will require some control structure on top of it, and it
_is_ OCF's crypto request and acrypto's crypto session.
But as far as I recall we did not agree on sync stack usage on
asynchronous processing :)
> 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
> ___
>
> Subscription: http://lists.logix.cz/mailman/listinfo/cryptoapi
> List archive: http://lists.logix.cz/pipermail/cryptoapi
--
Evgeniy Polyakov
-
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
RE: Dm-crypt patch for OCF
Hi I don't think there is any problem to let the read request to flow through, since in the original code, In order to decrypt the read requests, we create a new task (workingQ) that perform the decrypt, and doesn't notify any other task when it finish, except for the dec_pending(io,r) which I moved to the read callback. Regards Ronen Shitrit Marvell Semiconductor Israel Ltd -Original Message- From: Evgeniy Polyakov [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 07, 2005 10:36 AM To: Ronen Shitrit Cc: [EMAIL PROTECTED]; linux-crypto@vger.kernel.org Subject: Re: Dm-crypt patch for OCF On Tue, Sep 06, 2005 at 09:20:42PM +0300, Ronen Shitrit ([EMAIL PROTECTED]) wrote: > Hi Hello, Ronen. I have some doubts - you only wait on write request, but allow read request to flow through - when doind read request it does not mean, that dm-crypt is the last target, it can be even freed when your read callback will be called. And according to crypto sessions - I was confused by this name, and did not understood you from the first point. I want to say, that acrypto does not have such crypto session like OCF has. It only has crypto requests in OCF terminology, since it does not require special controlling strucutre on top of it. I will describe it in more details in different thread. > I improved the first patch, see attached. > > Dm-crypt: > -)On the encrypt(write) side we first allocate a new buffer then we > encrypt (using crypt_convert) the src buffer to the new buffer, we > send it > to be written through the generic_make_request(clone), then when the > clone->bi_end_io is called we free the buffer and the io. > -)On the decrypt(read) side we first read the buffer to the source > through the generic_make_request(clone), then when the clone->bi_end_io > is called, we create a new working thread which will decrypt (using > crypt_convert) the buffer and free the io. > > In the first patch, for each crypt_convert operation we send all the > sectors of the context to be encrypt/decrypt to the OCF, and then we > are waiting for A completion of all of these sectors before returning > from crypt_convert, i.e. we get a limitation that only one > encrypt/decrypt crypt_convert operation can occur in parallel. > > In the attached new patch, I removed this limitation for the > decrypt(read) crypt_convert, > By doing this I can see that when running the Bonnie benchmark, I get > better performance for the read/rewrite tests. > > The same approach can be used for the encrypt(write) crypt_convert, it > is a little bit more complicated then the decrypt(read), maybe I will > try to implement it in future patches. > > I also noticed that sometimes I get 2 encrypt(write) crypt_convert in > parallel?!?!, that why I moved the wr_pending into a separate > structure, > > which is allocated per write request. > This change affected the write performance only in a bit, less then 1%. > > btw - this patch is a patch for kernel 2.6.12, with OCF 20050630 patch > applied on it. > same tests were used as for the first patch. > > Regards > > Ronen Shitrit > Marvell Semiconductor Israel Ltd > > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ronen Shitrit > Sent: Monday, September 05, 2005 6:33 PM > To: [EMAIL PROTECTED]; linux-crypto@vger.kernel.org > Cc: Evgeniy Polyakov; David McCullough > Subject: 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 > encry
Re: Dm-crypt patch for OCF
On Tue, Sep 06, 2005 at 09:20:42PM +0300, Ronen Shitrit ([EMAIL PROTECTED]) wrote: > Hi Hello, Ronen. I have some doubts - you only wait on write request, but allow read request to flow through - when doind read request it does not mean, that dm-crypt is the last target, it can be even freed when your read callback will be called. And according to crypto sessions - I was confused by this name, and did not understood you from the first point. I want to say, that acrypto does not have such crypto session like OCF has. It only has crypto requests in OCF terminology, since it does not require special controlling strucutre on top of it. I will describe it in more details in different thread. > I improved the first patch, see attached. > > Dm-crypt: > -)On the encrypt(write) side we first allocate a new buffer then we > encrypt (using crypt_convert) the src buffer to the new buffer, we send > it > to be written through the generic_make_request(clone), then when the > clone->bi_end_io is called we free the buffer and the io. > -)On the decrypt(read) side we first read the buffer to the source > through the generic_make_request(clone), then when the clone->bi_end_io > is called, we create a new working thread which will decrypt (using > crypt_convert) the buffer and free the io. > > In the first patch, for each crypt_convert operation we send all the > sectors of the context to be encrypt/decrypt to the OCF, and then we are > waiting for > A completion of all of these sectors before returning from > crypt_convert, > i.e. we get a limitation that only one encrypt/decrypt crypt_convert > operation can occur in parallel. > > In the attached new patch, I removed this limitation for the > decrypt(read) crypt_convert, > By doing this I can see that when running the Bonnie benchmark, I get > better performance for the read/rewrite tests. > > The same approach can be used for the encrypt(write) crypt_convert, it > is a little bit more complicated then the decrypt(read), maybe I will > try to implement it in future patches. > > I also noticed that sometimes I get 2 encrypt(write) crypt_convert in > parallel?!?!, that why I moved the wr_pending into a separate structure, > > which is allocated per write request. > This change affected the write performance only in a bit, less then 1%. > > btw - this patch is a patch for kernel 2.6.12, with OCF 20050630 patch > applied on it. > same tests were used as for the first patch. > > Regards > > Ronen Shitrit > Marvell Semiconductor Israel Ltd > > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ronen Shitrit > Sent: Monday, September 05, 2005 6:33 PM > To: [EMAIL PROTECTED]; linux-crypto@vger.kernel.org > Cc: Evgeniy Polyakov; David McCullough > Subject: 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 > > ___ > > Subscription: http://lists.logix.cz/mailman/listinfo/cryptoapi > List archive: http://lists.logix.cz/pipermail/cryptoapi -- Evgeniy Polyakov - To unsubscribe from this list:
