Hi I already tried the solution you suggest below, it works fine but then we only handle one request at a time, and the performance doesn't look good. I also noticed that if I allow to insert up to a specific limit of pending requests lets say 10, then the driver acts fine, and the performance seems better. But If I let the limit to get to more then 100 pending requests, then I get memory corruption probably cause of some overrun.
I'm not sure if any pending requests is allowed at all, I will need to investigate it more. Regards Ronen Shitrit Marvell Semiconductor Israel Ltd -----Original Message----- From: Evgeniy Polyakov [mailto:[EMAIL PROTECTED] Sent: Sunday, September 04, 2005 11:52 PM To: Ronen Shitrit Cc: [EMAIL PROTECTED]; linux-crypto@vger.kernel.org Subject: Re: [ACRYPTO] dm-crypt ported to acrypto. On Sun, Sep 04, 2005 at 11:27:24PM +0300, Ronen Shitrit ([EMAIL PROTECTED]) wrote: > Hi > > I already ported this patch to the OCF, and I'm using it over the OCF. > I also don't see any issue with small partitions?? > > The crypt_convert API is called from 2 different places in the code: > 1. For read requests through the kcrypt_do_work working Q, called from > bi_end_io of the crypt_clone. > 2. For Write requests through the crypt_clone directly. Ok, I see now. Such schema was probably created to eliminate problem with buffer cache, when it is accessed from kernel itself and should not have encrypted data, but when it's data is wrtten to disk itself, BIOs should be already encrypted. > In my recent version of the patch: > I implemented a callback for read, which update the pending counter, > and callback for write Which doesn't update it. > And in the crypt_convert I update the pending counter only if it's a > read operation. > > By doing this I'm making sure that only one read request will be > handled at a time and the pending counter Will be updated correctly > for the read requests. > > Now, I still see that I'm getting few writing requests inside the > Acrypto Q at the same time. > I think it is not OK since currently the patch is not handling > buffers correctly for this case: the write task Believe that the write > was done, and it frees the buffers. (If I understood it correctly) ??? I think the best solution is just to put waiting for dm_async_pending to become zero into crypt_convert(). Patch attached. I will setup large partition tomorrow and send my results with it. Thank you for catching this. > > I will send a patch, once the dm_crypt will be stable with the OCF. > > Ronen Shitrit > Marvell Semiconductor Israel Ltd -- 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
