Patches start from 5 because pathches 1..4 are already
in cryptodev-2.6.
camellia5:
adds 64-bit key setup, it is used if BITS_PER_LONG is 64.
camellia6:
unifies encrypt/decrypt routines for different key lengths.
This reduces module size by ~25%, with tiny (less than 1%)
speed impact.
Also collapses encrypt/decrypt into more readable
(visually shorter) form using macros.
camellia7:
Move "key XOR is end of F-function" code part into
camellia_setup_tail(), it is sufficiently similar
between camellia_setup128 and camellia_setup256.
camellia8:
Analogously to camellia7 patch, move
"absorb kw2 to other subkeys" and "absorb kw4 to other subkeys"
code parts into camellia_setup_tail(). This further reduces
source and object code size at the cost of two brances
in key setup code.
Code sizes:
64-bit:
dec hex filename
22786 5902 2.6.23.1.camellia4.t64/crypto/camellia.o
21422 53ae 2.6.23.1.camellia5.t64/crypto/camellia.o
16355 3fe3 2.6.23.1.camellia6.t64/crypto/camellia.o
15813 3dc5 2.6.23.1.camellia7.t64/crypto/camellia.o
15670 3d36 2.6.23.1.camellia8.t64/crypto/camellia.o
32-bit:
29948 74fc 2.6.23.1.camellia4.t/crypto/camellia.o
29457 7311 2.6.23.1.camellia5.t/crypto/camellia.o
21414 53a6 2.6.23.1.camellia6.t/crypto/camellia.o
20518 5026 2.6.23.1.camellia7.t/crypto/camellia.o
18454 4816 2.6.23.1.camellia8.t/crypto/camellia.oamellia.o
These patches apply cleanly to current cryptodev-2.6.
They should be applied in order.
Compile and run tested.
Signed-off-by: Denys Vlasenko <[email protected]>
--
vda
On Wednesday 21 November 2007 00:22, Denys Vlasenko wrote:
> Patches start from 5 because pathches 1..4 are already
> in cryptodev-2.6.
>
> camellia5:
> adds 64-bit key setup, it is used if BITS_PER_LONG is 64.
>
Signed-off-by: Denys Vlasenko <[email protected]>
--
vda
On Wednesday 21 November 2007 00:22, Denys Vlasenko wrote:
> camellia6:
> unifies encrypt/decrypt routines for different key lengths.
> This reduces module size by ~25%, with tiny (less than 1%)
> speed impact.
> Also collapses encrypt/decrypt into more readable
> (visually shorter) form using macros.
Signed-off-by: Denys Vlasenko <[email protected]>
--
vda
On Wednesday 21 November 2007 00:22, Denys Vlasenko wrote:
> camellia7:
> Move "key XOR is end of F-function" code part into
> camellia_setup_tail(), it is sufficiently similar
> between camellia_setup128 and camellia_setup256.
Signed-off-by: Denys Vlasenko <[email protected]>
--
vda
On Wednesday 21 November 2007 00:22, Denys Vlasenko wrote:
> camellia8:
> Analogously to camellia7 patch, move
> "absorb kw2 to other subkeys" and "absorb kw4 to other subkeys"
> code parts into camellia_setup_tail(). This further reduces
> source and object code size at the cost of two brances
> in key setup code.
I also tried to more more code into tail, but it becomes
more complicated. Up to this point is was straightforward.
Signed-off-by: Denys Vlasenko <[email protected]>
I noticed that in [PATCH 2/4] and [PATCH 3/4] mails
I attached linux-2.6.23.1xxxxxxxxxx.diff files.
This is not a problem, the patches are actually
identical to cryptodev-2.6xxxxxxxxxxxx.diff ones,
except for leading directory prefix.
I verified that they do apply without rejects,
offsets or fuzz to cryptodev-2.6.
--
vda
On Wed, Nov 21, 2007 at 12:25:10AM -0800, Denys Vlasenko wrote:
> On Wednesday 21 November 2007 00:22, Denys Vlasenko wrote:
> > camellia6:
> > unifies encrypt/decrypt routines for different key lengths.
> > This reduces module size by ~25%, with tiny (less than 1%)
> > speed impact.
> > Also collapses encrypt/decrypt into more readable
> > (visually shorter) form using macros.
>
> Signed-off-by: Denys Vlasenko <[email protected]>
Sorry, this doesn't apply without applying 1/4.
You couldn't have picked a better patch order :)
Seriously, you'll make both of us happier if you put the easy
patches first and the contentious stuff at the end.
Thanks,
--
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 Wed, Nov 21, 2007 at 12:23:49AM -0800, Denys Vlasenko wrote:
> On Wednesday 21 November 2007 00:22, Denys Vlasenko wrote:
> > Patches start from 5 because pathches 1..4 are already
> > in cryptodev-2.6.
> >
> > camellia5:
> > adds 64-bit key setup, it is used if BITS_PER_LONG is 64.
> >
> Signed-off-by: Denys Vlasenko <[email protected]>
Denys, I really appreciate your work in cleaning this algorithm up.
However, I just can't accept 600 lines of new code just to do setkey
faster/smaller on 64-bit platforms. You know, some people have to
study these files line-by-line in order have them pass government
certifications and such.
OK I went back and looked at the figures, so we're talking about
either 1K extra on 64-bit if we use the 32-bit version or 2K extra
on 32-bit if we went for the 64-bit version.
Either way it doesn't seem to be a big deal. So how about just
picking one and sticking with it?
Thanks,
--
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 Thursday 22 November 2007 04:25, Herbert Xu wrote:
> On Wed, Nov 21, 2007 at 12:23:49AM -0800, Denys Vlasenko wrote:
> > On Wednesday 21 November 2007 00:22, Denys Vlasenko wrote:
> > > Patches start from 5 because pathches 1..4 are already
> > > in cryptodev-2.6.
> > >
> > > camellia5:
> > > adds 64-bit key setup, it is used if BITS_PER_LONG is 64.
> >
> > Signed-off-by: Denys Vlasenko <[email protected]>
>
> Denys, I really appreciate your work in cleaning this algorithm up.
>
> However, I just can't accept 600 lines of new code just to do setkey
> faster/smaller on 64-bit platforms. You know, some people have to
> study these files line-by-line in order have them pass government
> certifications and such.
480 lines after all patches are applied.
> OK I went back and looked at the figures, so we're talking about
> either 1K extra on 64-bit if we use the 32-bit version or 2K extra
> on 32-bit if we went for the 64-bit version.
>
> Either way it doesn't seem to be a big deal. So how about just
> picking one and sticking with it?
"No big deal" approach resulted in thish module having 30k of code.
I cut it down to 20-18k.
In aic7xxx driver, similarly, I rediced size from 300k to 200k.
Still not in mainline. This is depressing.
I am an -Os guy and for me 1k out of 20k module doesn't sound too small.
I will rework and repost patches so that 64-bit code is added by last
patch, feel free to not apply it.
--
vda