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
