Hi:
I've developed a series of patches that speed up the operations of crypt()
based on the generic scatterwalk patch by Fruhwirth Clemens. My testing
shows that the results are comparable to that of the original patch.
What I found is that the primary source of the boost in performance is
the change that results in one pair of kmap operations per page instead
of one set per block as is done currently. Since the average block size
is around 8/16 bytes this is understandable.
Apart from that eliminating unnecessary out-of-line function calls for
the fast path in crypt() also helps quite a lot.
Please let me know if you find any problems with these patches.
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
Hi:
scatterwalk_whichbuf is called once for each block which could be as
small as 8/16 bytes. So it makes sense to do that work inline.
It's also a bit inflexible since we may want to use the temporary buffer
even if the block doesn't cross page boundaries. In particular, we want
to do that when the source and destination are the same.
So let's replace it with scatterwalk_across_pages.
I've also simplified the check in scatterwalk_across_pages. It is
sufficient to only check len_this_page.
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
Hi:
Move the handling of in_place into crypt() itself. This means that we only
need two temporary buffers instead of three. It also allows us to simplify
the check in scatterwalk_samebuf.
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
Hi:
Perform kmap once (or twice if the buffer is not aligned correctly)
per page in crypt() instead of the current code which does it once
per block. Consequently it will yield once per page instead of once
per block.
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
Hi:
Only call scatterwalk_copychunks when the block straddles a page boundary.
This allows crypt() to skip the out-of-line call most of the time.
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
Hi:
Move src/dst handling from crypt() into the helpers prepare_src,
prepare_dst, complete_src and complete_dst. complete_src doesn't
actually do anything at the moment but is included for completeness.
This sets the stage for further optimisations down the track without
polluting crypt() itself.
These helpers don't belong in scatterwalk.[ch] since they only help
the particular way that crypt() is walking the scatter lists.
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
On Mon, 2005-03-21 at 20:53 +1100, Herbert Xu wrote:
> Perform kmap once (or twice if the buffer is not aligned correctly)
> per page in crypt() instead of the current code which does it once
> per block. Consequently it will yield once per page instead of once
> per block.
Thanks for your work, Herbert.
Applying all patches results in a "does not work for me". The decryption
result is different from the original and my LUKS managed partition
refuses to mount.
I assume you have a test environment already setup, so I would suggest
to find out up to which patch the following test succeeds (should be
paste-able)
cd /tmp
dd if=/dev/zero of=test-crypt count=100
losetup /dev/loop5 /tmp/test-crypt
echo 0 100 crypt aes-plain 0123456789abcdef0123456789abcdef 0 /dev/loop5 0 | dmsetup create test-map
sha1sum /dev/mapper/test-map
Result:
368d017dbdb4299ed7f27d3fc815442f7e438865 /dev/mapper/test-map
Cheers,
--
Fruhwirth Clemens - http://clemens.endorphin.org
for robots: [email protected]
On Mon, Mar 21, 2005 at 12:30:59PM +0100, Fruhwirth Clemens wrote:
>
> Applying all patches results in a "does not work for me". The decryption
> result is different from the original and my LUKS managed partition
> refuses to mount.
Thanks for testing this Fruhwirth. The problem is that walk->data wasn't
being incremented anymore after my last change. This patch should fix it
up.
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
On Tue, 2005-03-22 at 12:13 +1100, Herbert Xu wrote:
> On Mon, Mar 21, 2005 at 12:30:59PM +0100, Fruhwirth Clemens wrote:
> >
> > Applying all patches results in a "does not work for me". The decryption
> > result is different from the original and my LUKS managed partition
> > refuses to mount.
>
> Thanks for testing this Fruhwirth. The problem is that walk->data wasn't
> being incremented anymore after my last change.
I remember, that I almost forgot about that pointer too.
> This patch should fix it up.
Works for me now. Thanks.
--
Fruhwirth Clemens - http://clemens.endorphin.org
for robots: [email protected]
Hi:
Here's some more optimisations plus a bug fix for a pathological case
where in_place might not be set correctly which can't happen with any
of the current users. Here is the first one:
We have long since stopped using a null cit_iv as a means of doing null
encryption. In fact it doesn't work here anyway since we need to copy
src into dst to achieve null encryption.
No user of cbc_encrypt_iv/cbc_decrypt_iv does this either so let's just
get rid of this check which is sitting in the fast path.
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
Hi:
Rather than taking a branch on the fast path, we might as well split
cbc_process into encrypt and decrypt since they don't share anything
in common.
We can get rid of the cryptfn argument too. I'll do that next.
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
Hi:
This is needed so that we can keep the in_place assignment outside the
inner loop. Without this in pathalogical situations we can start out
having walk_out being different from walk_in, but when walk_out crosses
a page it may converge with walk_in.
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
On Tue, 22 Mar 2005 22:25:04 +1100
Herbert Xu <[email protected]> wrote:
> Hi:
>
> This is needed so that we can keep the in_place assignment outside the
> inner loop. Without this in pathalogical situations we can start out
> having walk_out being different from walk_in, but when walk_out crosses
> a page it may converge with walk_in.
All 9 patches applied, thanks Herbert.
Patches 7 through 9 were generated differently from the others,
look at the directory prefixes (or rather, a lack thereof):
===== cipher.c 1.26 vs edited =====
--- 1.26/crypto/cipher.c 2005-03-22 21:56:21 +11:00
+++ edited/cipher.c 2005-03-22 21:59:53 +11:00
I had to hand edit these before sending them through my patch
application scripts which expect -p1 diffs ;-)