ocf-linux-users — Anything and everything ocf-linux related

[Ocf-linux-users] Geode AES Engine and ocf - not working?

[Kevin F. <ke...@wh...>]

Hi there!

I am trying to use ocf-linux to get my geode aes engine up and running
for vpn encryption. After days of patching an recompiling on and on i
finally got everything working ... i thought.

My kernel has ocf linux compiled in and geode_aes, cryptodev +
cryptosoft (for testing) compiled as modules.
My Openssl has the cryptodev patch and lists the cryptodev engine, but
if i encrypt something with and without cryptodev the performance is the
same.

Maybe someone has an idea or already expirience something like this?
Did i forget something?

Greets

Kevin

Re: [Ocf-linux-users] OpenSSL / AES192-CBC

[David M. <Dav...@se...>]

Jivin Daniel Mueller lays it down ...
> Hi,
> 
> was there any reason to not include aes192-cbc in the OpenSSL patch? I
> had no problems after applying the attached patch.

No :-)

I have applied your patch so any future stuff I release will have it,

Thanks,
Davidm

-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org   http://www.snapgear.com

[Ocf-linux-users] OpenSSL / AES192-CBC

[Daniel M. <da...@da...>]

Hi,

was there any reason to not include aes192-cbc in the OpenSSL patch? I
had no problems after applying the attached patch.

bye, danm

-- 
Daniel Mueller          http://www.danm.de
Berlin, Germany         OpenPGP: F9F982C1

[Ocf-linux-users] ocf, linux-2.6.26

[John G. <joh...@ta...>]

Folks

FWIW enclosed is a trivial patch to get ocf-linux-20080704.tar.gz up and
running on linux-2.6.26

The entropy addition bit could probably use some review.

I also need to bodge the pci IDs for the hifn cards. Patch enclosed.
Need to do that on 2.6.25 also.

cheers

John

[Ocf-linux-users] FW: kernel panic, hifn7751, digests

[John G. <joh...@ta...>]

Folks

FWIW I still see this panic in ocf-linux-20080704.tar.gz
Patch seems to fix it.

Cheers

John

-----Original Message-----
From: ocf...@li...
[mailto:ocf...@li...] On Behalf Of John
Gumb
Sent: 20 June 2008 19:54
To: ocf...@li...
Subject: [Ocf-linux-users] kernel panic, hifn7751, digests

Folks

Between ocf-linux-20060331 and ocf-linux-20071215 something got into the
hifn driver which causes a kernel panic under load calculating digests.

By pretty much brute force I think I've tracked down what's causing it.

The patch kinda speaks for itself but its all related to moving towards
a common crypto_copyback function. Reinstating crp->crp_mac rather than
using crp->crp_buf and the complexity that entails in
crypto_copyback/cuio_copyback seems to fix it.

I don't pretend to understand this but it does seem to work for us.

As I say, the crash only happens under heavy load and if I have
ENABLE_DIGESTS on in the openssl eng_cryptodev.c

Just thought I'd let you know or might help someone.

Patch and panic signature attached.

cheers

John Gumb

[Ocf-linux-users] Packets dropped and sequence id is decremented at high transfer rate

[Vrabete, B. <bra...@in...>]

---------------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: One Spencer Dock, North Wall Quay, Dublin 1
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

[Ocf-linux-users] Session migration (OCF_20071215)

[Vrabete, B. <bra...@in...>]

---------------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: One Spencer Dock, North Wall Quay, Dublin 1
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [Ocf-linux-users] OCF 20080704 and 2.6.21.6 Kernel

[David M. <Dav...@se...>]

Jivin "Ramon Schönborn" lays it down ...
> Hi David & List,
> > > > > I guess there's a bug in pfkey_v2_parser.c, btw. If you compare the
> > > > > old 2.4.8 Version with the current one, a pair of curly braces
> > changed
> > > > > the semantic.
> > > > > >From Line 2126 it should be like:
> > > > > -               if ((error = ipsec_cleareroutes())) {
> > > > > +               if ((error = ipsec_cleareroutes()))
> > > > >                         KLIPS_PRINT(debug_pfkey,
> > > > >                                    
> > "klips_debug:pfkey_x_delflow_parse:
> > > > "
> > > > >                                     "cleareroutes returned %d.\n",
> > > > error);
> > > > >                         SENDERR(-error);
> > > > > -               }
> > > > > +
> > > >
> > > > That is definately a problem but it looks like we already found it :-)
> > > > My code has the fix so I am guessing you need to try 2.6.16dr4,  which
> > > > is what I have running here.  It has settled down now but there was a
> > "dr"
> > > > release every day there for a bit ;-)
> > > 
> > > isnt fixed in 2.6.16dr4 yet. I forgot to mention that i'm already
> > testing
> > > 2.6.16dr4 too.
> > 
> > Ok,  I misread what you were saying and I see the code change.
> > 
> > Is this change causing you a problem ?  IMO is looks like it was always
> > a bug as the code hasn't detected any errors yet does a jump to errlab
> > by calling SENDERR(-0).
> > 
> > I'll copy Paul Wouters at Xelerance to see what his thoughts are.
>
> it was causing me the problem that "ipsec eroute --clear" didnt work 
> anymore. It seems to me that calling SENDERR(-0) was just an quick and
> dirty - though working -  trick to finish the "clear"-Request.

Its definately possible,  but it didn't look right.  I imagine I changed it
during the big ocf-merge because it didn't look right.

If it is causing you problems then I say back out the change ;-)

Cheers,
Davidm

-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org   http://www.snapgear.com

Re: [Ocf-linux-users] OCF 20080704 and 2.6.21.6 Kernel

[Ramon S. <RSc...@gm...>]

Hi David & List,
> > > > I guess there's a bug in pfkey_v2_parser.c, btw. If you compare the
> > > > old 2.4.8 Version with the current one, a pair of curly braces
> changed
> > > > the semantic.
> > > > >From Line 2126 it should be like:
> > > > -               if ((error = ipsec_cleareroutes())) {
> > > > +               if ((error = ipsec_cleareroutes()))
> > > >                         KLIPS_PRINT(debug_pfkey,
> > > >                                    
> "klips_debug:pfkey_x_delflow_parse:
> > > "
> > > >                                     "cleareroutes returned %d.\n",
> > > error);
> > > >                         SENDERR(-error);
> > > > -               }
> > > > +
> > >
> > > That is definately a problem but it looks like we already found it :-)
> > > My code has the fix so I am guessing you need to try 2.6.16dr4,  which
> > > is what I have running here.  It has settled down now but there was a
> "dr"
> > > release every day there for a bit ;-)
> > 
> > isnt fixed in 2.6.16dr4 yet. I forgot to mention that i'm already
> testing
> > 2.6.16dr4 too.
> 
> Ok,  I misread what you were saying and I see the code change.
> 
> Is this change causing you a problem ?  IMO is looks like it was always
> a bug as the code hasn't detected any errors yet does a jump to errlab
> by calling SENDERR(-0).
> 
> I'll copy Paul Wouters at Xelerance to see what his thoughts are.
> 
it was causing me the problem that "ipsec eroute --clear" didnt work 
anymore. It seems to me that calling SENDERR(-0) was just an quick and
dirty - though working -  trick to finish the "clear"-Request.

Cheers & thanks for your support,
Ramon

-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

Re: [Ocf-linux-users] OCF 20080704 and 2.6.21.6 Kernel

[David M. <Dav...@se...>]

Jivin "Ramon Schönborn" lays it down ...
> > > Hello OCF-Linux-Users,
> > >
> > > i'm trying to run the latest OCF 20080704 Release together with
> > > linux-2.6.21.6 Kernel + Openswan 2.6.15dr2 on an IXP4XX Architecture.
> > >
> > > I have a Question concerning Config Options:
> > > - In the OCF Package, in File linux/net/ipsec/defconfig and
> > > packaging/linux/Config-all.h, CONFIG_KLIPS_OCF is not set while
> > > CONFIG_KLIPS_ALG is set to y.
> >
> > This is the default for non-ocf builds.
> 
> okay, that did confuse me a bit because:
> - i didnt found any hint to tweak this config files
> - i didnt expect this behaviour for a patch. If i dont want a patch to
> do something, i wouldnt apply it ...

Well it's no longer a patch,  it's part of openswan proper,  and by
default the openswan guys don't want OCF enabled since it requires a
kernel patch.

Still, it's just house keeping really.

> > > According to the info in KConfig,
> > > KLIPS_ALG should only be disabled when OCF is used - which setting
> > > is right?
> >
> > I thought that read "may" only be disabled when using OCF,  but perhaps
> > that fix got lost ;-)
> 
> okay, that was just c&p from my mind ;-)

No probs.

> > > My guess is: KLIPS_ALG is necessary, but it results in Error when
> > > used together with KLIPS_OCF set (see ipsec_xmit.c).
> >
> > If you are going to use OCF and you want to reduce the size of your
> > kernel then you turn on CONFIG_KLIPS_OCF and turn off CONFIG_KLIPS_ALG.
> > You can then disable all the crypto options in openswan IIRC,  you can
> > also disable most of the cryptoapi drivers.
> >
> > The reason you can do this is that OCF is effectively a full replacement
> > for the ALG code.  And if you have a HW driver,  you do not need the SW
> > crypto either.
> >
> > Does that make any sense ?
> I think so.
> What i meant with "see ipsec_xmit.c": about line 1568 (2.6.16dr4) we have a
> line of code: ixs->ixt_e=ixs->ipsp->ips_alg_enc;
> The Problem with this line occurs, when both KLIPS_ALG and KLIPS_OCF are
> defined - then this line becomes the "else"-branch of the if-command in the
> previous OCF-dependend block of code. The following if (ixs->ixt_e) { ...
> will be executed afterwards, though this will result in an error
> (IPSEC_XMIT_ESP_BADALG) later.

Yep,  missed that thanks.  patch attached.

> > > Mysteriously, my IPSec tunnel is established with:
> > > "IPsecConn-0" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel
> > mode {ESP=>0x5f6f06b7 <0x785d1973 xfrm=AES_128-HMAC_MD5 NATOA=none
> > NATD=none DPD=none}"
> > > , and incomming Packets can be decrypted. Outgoing Packets instead
> > result in increasing TX Error Counter
> > > and a BADALG Error Message (if both, KLIPS_ALG and KLIPS_OCF are set).
> > >
> 
> like i just tried to explain: that was the reason why i expexted KLIPS_ALG and
> KLIPS_OCF to be mutual exclusive.

They are supposed to work together so if they don't we have bugs to fix.
I must admit, I probably didn't do much more than bring the tunnels up
when I was testing.  I will try and revisit soon.

> Unfortunately, when i have only KLIPS_OCF
> defined, the behaviour is nearly the same (tunnel established, encrypting
> fails) but i dont get an error message.
> Do you have any idea why this happens? The only useful debugging output i
> have is:
> Mar  1 00:02:49 IF1xxx kern.info IF1xxx kernel: klips_debug:ipsec_alg_esp_encrypt: entering with encalg=12, ixt_e=bf1ec080
> Mar  1 00:02:49 IF1xxx kern.info IF1xxx kernel: klips_debug:ipsec_alg_esp_encrypt: calling cbc_encrypt encalg=12 ips_key_e=c250e400 idat=c2c7824c ilen=96 iv=c2c7823c, encrypt=1
> Mar  1 00:02:49 IF1xxx kern.info IF1xxx kernel: klips_debug:ipsec_alg_esp_encrypt: returned ret=96
> ...
> (some klips_dmp output)
> ...
> Mar  1 00:02:49 IF1xxx kern.info IF1xxx kernel: klips_debug:ipsec_findroute: 192.168.0.254:0->192.168.0.253:0 50
> Mar  1 00:02:49 IF1xxx kern.info IF1xxx kernel: klips_debug:rj_match: * See if we match exactly as a host destination
> Mar  1 00:02:49 IF1xxx kern.info IF1xxx kernel: klips_debug:rj_match: ** try to match a leaf, t=0pc3680620
> Mar  1 00:02:49 IF1xxx kern.info IF1xxx kernel: klips_debug:rj_match: *** start searching up the tree, t=0pc3680620
> Mar  1 00:02:49 IF1xxx kern.info IF1xxx kernel: klips_debug:rj_match: **** t=0pc3680638
> Mar  1 00:02:49 IF1xxx kern.info IF1xxx kernel: klips_debug:rj_match: **** t=0pc2d64d60
> Mar  1 00:02:49 IF1xxx kern.info IF1xxx kernel: klips_debug:rj_match: ***** cp2=0pc3016148 cp3=0pc2d65830
> Mar  1 00:02:49 IF1xxx kern.info IF1xxx kernel: klips_debug:rj_match: ***** not found.
> (then nothing happens)

Seems like some problem with the tunnel addressing/association.

> Please not that the following bug is independent of the Problem decribed above:

ok.

> > > I guess there's a bug in pfkey_v2_parser.c, btw. If you compare the
> > > old 2.4.8 Version with the current one, a pair of curly braces changed
> > > the semantic.
> > > >From Line 2126 it should be like:
> > > -               if ((error = ipsec_cleareroutes())) {
> > > +               if ((error = ipsec_cleareroutes()))
> > >                         KLIPS_PRINT(debug_pfkey,
> > >                                     "klips_debug:pfkey_x_delflow_parse:
> > "
> > >                                     "cleareroutes returned %d.\n",
> > error);
> > >                         SENDERR(-error);
> > > -               }
> > > +
> >
> > That is definately a problem but it looks like we already found it :-)
> > My code has the fix so I am guessing you need to try 2.6.16dr4,  which
> > is what I have running here.  It has settled down now but there was a "dr"
> > release every day there for a bit ;-)
> 
> isnt fixed in 2.6.16dr4 yet. I forgot to mention that i'm already testing
> 2.6.16dr4 too.

Ok,  I misread what you were saying and I see the code change.

Is this change causing you a problem ?  IMO is looks like it was always
a bug as the code hasn't detected any errors yet does a jump to errlab
by calling SENDERR(-0).

I'll copy Paul Wouters at Xelerance to see what his thoughts are.

Cheers,
Davidm


-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org   http://www.snapgear.com

Re: [Ocf-linux-users] OCF 20080704 and 2.6.21.6 Kernel

[David M. <Dav...@se...>]

Jivin "Ramon Schönborn" lays it down ...
> Hello OCF-Linux-Users,
> 
> i'm trying to run the latest OCF 20080704 Release together with 
> linux-2.6.21.6 Kernel + Openswan 2.6.15dr2 on an IXP4XX Architecture.
> 
> I have a Question concerning Config Options:
> - In the OCF Package, in File linux/net/ipsec/defconfig and
> packaging/linux/Config-all.h, CONFIG_KLIPS_OCF is not set while
> CONFIG_KLIPS_ALG is set to y.

This is the default for non-ocf builds.

> According to the info in KConfig,
> KLIPS_ALG should only be disabled when OCF is used - which setting
> is right?

I thought that read "may" only be disabled when using OCF,  but perhaps
that fix got lost ;-)

> My guess is: KLIPS_ALG is necessary, but it results in Error when
> used together with KLIPS_OCF set (see ipsec_xmit.c).

If you are going to use OCF and you want to reduce the size of your
kernel then you turn on CONFIG_KLIPS_OCF and turn off CONFIG_KLIPS_ALG.
You can then disable all the crypto options in openswan IIRC,  you can
also disable most of the cryptoapi drivers.

The reason you can do this is that OCF is effectively a full replacement
for the ALG code.  And if you have a HW driver,  you do not need the SW
crypto either.

Does that make any sense ?

> Mysteriously, my IPSec tunnel is established with:
> "IPsecConn-0" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0x5f6f06b7 <0x785d1973 xfrm=AES_128-HMAC_MD5 NATOA=none NATD=none DPD=none}"
> , and incomming Packets can be decrypted. Outgoing Packets instead result in increasing TX Error Counter
> and a BADALG Error Message (if both, KLIPS_ALG and KLIPS_OCF are set).
> 
> I guess there's a bug in pfkey_v2_parser.c, btw. If you compare the
> old 2.4.8 Version with the current one, a pair of curly braces changed
> the semantic.
> >From Line 2126 it should be like:
> -               if ((error = ipsec_cleareroutes())) {
> +               if ((error = ipsec_cleareroutes())) 
>                         KLIPS_PRINT(debug_pfkey,
>                                     "klips_debug:pfkey_x_delflow_parse: "
>                                     "cleareroutes returned %d.\n", error);
>                         SENDERR(-error);
> -               }
> +            

That is definately a problem but it looks like we already found it :-)
My code has the fix so I am guessing you need to try 2.6.16dr4,  which
is what I have running here.  It has settled down now but there was a "dr"
release every day there for a bit ;-)

Cheers,
Davidm

-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org   http://www.snapgear.com

[Ocf-linux-users] OCF 20080704 and 2.6.21.6 Kernel

[Ramon S. <RSc...@gm...>]

Hello OCF-Linux-Users,

i'm trying to run the latest OCF 20080704 Release together with 
linux-2.6.21.6 Kernel + Openswan 2.6.15dr2 on an IXP4XX Architecture.

I have a Question concerning Config Options:
- In the OCF Package, in File linux/net/ipsec/defconfig and
packaging/linux/Config-all.h, CONFIG_KLIPS_OCF is not set while
CONFIG_KLIPS_ALG is set to y. According to the info in KConfig,
KLIPS_ALG should only be disabled when OCF is used - which setting
is right?
My guess is: KLIPS_ALG is necessary, but it results in Error when
used together with KLIPS_OCF set (see ipsec_xmit.c).
Mysteriously, my IPSec tunnel is established with:
"IPsecConn-0" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0x5f6f06b7 <0x785d1973 xfrm=AES_128-HMAC_MD5 NATOA=none NATD=none DPD=none}"
, and incomming Packets can be decrypted. Outgoing Packets instead result in increasing TX Error Counter
and a BADALG Error Message (if both, KLIPS_ALG and KLIPS_OCF are set).

I guess there's a bug in pfkey_v2_parser.c, btw. If you compare the
old 2.4.8 Version with the current one, a pair of curly braces changed
the semantic.
>From Line 2126 it should be like:
-               if ((error = ipsec_cleareroutes())) {
+               if ((error = ipsec_cleareroutes())) 
                        KLIPS_PRINT(debug_pfkey,
                                    "klips_debug:pfkey_x_delflow_parse: "
                                    "cleareroutes returned %d.\n", error);
                        SENDERR(-error);
-               }
+            

Greetings, Ramon
-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx

Re: [Ocf-linux-users] No performances improvment with AMD Geode

[Andreas S. <a.s...@go...>]

Hi,

we saw the following improvement of AES:



# openssl engine
(dynamic) Dynamic engine loading support

# openssl speed -evp aes-128-cbc -engine dynamic
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc       7091.41k    10286.25k    11557.60k    12058.76k    12157.67k



changed to


# openssl engine
(cryptodev) BSD cryptodev engine
(padlock) VIA PadLock (no-RNG, no-ACE)
(dynamic) Dynamic engine loading support

# openssl speed -evp aes-128-cbc
type             16 bytes     64 bytes    256 bytes   1024 bytes   2048 bytes
aes-128-cbc      65098.13k    92264.00k   410205.87k  5833523.20k  7599923.20k


If you have further questions, don't hesitate to ask me.

Best,
Andreas

On Fri, Jul 11, 2008 at 12:47 AM, David McCullough
<Dav...@se...> wrote:
>
> Jivin "Adam Cécile (Le_Vert)" lays it down ...
>> David McCullough a écrit :
>> >Jivin "Adam Cécile (Le_Vert)" lays it down ...
>> >...
>> >
>> >>gandalf@wrap:~$ cat /etc/modules
>> >># /etc/modules: kernel modules to load at boot time.
>> >>#
>> >># This file contains the names of kernel modules that should be loaded
>> >># at boot time, one per line. Lines beginning with "#" are ignored.
>> >>
>> >># Geode WatchDog
>> >>geodewdt
>> >>
>> >># Geode LX AES hardware crypto
>> >>geode-aes
>> >>geode-rng
>> >>crypto_blkcipher
>> >>ocf
>> >>cryptosoft
>> >>cryptodev
>> >>
>> >># Alix LEDs driver
>> >>leds-alix
>> >>
>> >># Sensors
>> >>lm90
>> >>
>> >>wrap:/home/gandalf# openssl speed -evp aes128 -elapsed
>> >>You have chosen to measure elapsed time instead of user CPU time.
>> >>To get the most accurate results, try to run this
>> >>program when this computer is idle.
>> >>Doing aes-128-cbc for 3s on 16 size blocks: 104083 aes-128-cbc's in 3.00s
>> >>Doing aes-128-cbc for 3s on 64 size blocks: 101925 aes-128-cbc's in 3.00s
>> >>Doing aes-128-cbc for 3s on 256 size blocks: 89677 aes-128-cbc's in 3.00s
>> >>Doing aes-128-cbc for 3s on 1024 size blocks: 61529 aes-128-cbc's in 3.00s
>> >>Doing aes-128-cbc for 3s on 2048 size blocks: 42862 aes-128-cbc's in 3.00s
>> >>OpenSSL 0.9.8g 19 Oct 2007
>> >>built on: Wed Jul  9 18:31:21 UTC 2008
>> >>options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long)
>> >>aes(partial) blowfish(idx)
>> >>compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT
>> >>-DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DL_ENDIAN -DTERMIO -O3
>> >>-march=i586 -Wa,--noexecstack -g -Wall -DOPENSSL_BN_ASM_PART_WORDS
>> >>-DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
>> >>available timing options: TIMES TIMEB HZ=100 [sysconf value]
>> >>timing function used: ftime
>> >>The 'numbers' are in 1000s of bytes per second processed.
>> >>type             16 bytes     64 bytes    256 bytes   1024 bytes   2048
>> >>bytes
>> >>aes-128-cbc        555.11k     2173.68k     7652.44k    21001.90k
>> >>29260.46k
>> >>
>> >>wrap:/home/gandalf# lsmod | grep cry
>> >>crypto_blkcipher       18564  1 geode_aes
>> >>wrap:/home/gandalf# lsmod | grep ocf
>> >>wrap:/home/gandalf# openssl speed -evp aes128 -elapsed
>> >>You have chosen to measure elapsed time instead of user CPU time.
>> >>To get the most accurate results, try to run this
>> >>program when this computer is idle.
>> >>Doing aes-128-cbc for 3s on 16 size blocks: 895899 aes-128-cbc's in 3.00s
>> >>Doing aes-128-cbc for 3s on 64 size blocks: 324390 aes-128-cbc's in 3.00s
>> >>Doing aes-128-cbc for 3s on 256 size blocks: 92243 aes-128-cbc's in 3.00s
>> >>Doing aes-128-cbc for 3s on 1024 size blocks: 23823 aes-128-cbc's in 3.00s
>> >>Doing aes-128-cbc for 3s on 2048 size blocks: 11998 aes-128-cbc's in 3.00s
>> >>OpenSSL 0.9.8g 19 Oct 2007
>> >>built on: Wed Jul  9 18:31:21 UTC 2008
>> >>options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long)
>> >>aes(partial) blowfish(idx)
>> >>compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT
>> >>-DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DL_ENDIAN -DTERMIO -O3
>> >>-march=i586 -Wa,--noexecstack -g -Wall -DOPENSSL_BN_ASM_PART_WORDS
>> >>-DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
>> >>available timing options: TIMES TIMEB HZ=100 [sysconf value]
>> >>timing function used: ftime
>> >>The 'numbers' are in 1000s of bytes per second processed.
>> >>type             16 bytes     64 bytes    256 bytes   1024 bytes   2048
>> >>bytes
>> >>aes-128-cbc       4778.13k     6920.32k     7871.40k     8131.58k
>> >>8190.63k
>> >>
>> >>Okay there's performance difference when I unload all ocf/cryptodev
>> >>kernel modules. But are you sure it comes from hardware ? It may just
>> >>come from the fact that ocf software perform better than the standard
>> >>linux crypto stack. What's your mind about this ?
>> >>
>> >
>> >If ocf is using software crypto it can never (on a single crypto stream)
>> >go faster than openssl (or kernel crypto) without ocf.  It's just not
>> >possible since they are all using basically the same crypto code on the
>> >same speed CPU.
>> >
>> >So yes,  I am sure you are doing HW crypto using OCF+cryptosoft and geode.
>> >
>> >It would go even faster if you ran it from in the kernel.  This is what
>> >the ocf-bench driver does if you are interested:
>> >
>> >     modprobe ocf-bench
>> >     dmesg
>> >
>> >Cheers,
>> >Davidm
>> >
>> Hello,
>>
>> I've just rebuild my kernel with ocf-bench. Here is what happens:
>> gandalf@wrap:~$ sudo modprobe ocf-bench
>> [sudo] password for root:
>> FATAL: Error inserting ocf_bench
>> (/lib/modules/2.6.25-2-alix/kernel/crypto/ocf/o
>> cf-bench.ko): Invalid argument
>> gandalf@wrap:~$ dmesg | tail
>> [   44.840932] wan: no IPv6 routers present
>> [   61.510480] ip6_tables: (C) 2000-2006 Netfilter Core Team
>> [   66.773388] warning: `named' uses 32-bit capabilities (legacy support
>> in use)
>> [   74.301323] tun: Universal TUN/TAP device driver, 1.6
>> [   74.301346] tun: (C) 1999-2004 Max Krasnyansky <ma...@qu...>
>> [   74.307817] tun0: Disabled Privacy Extensions
>> [   82.660103] wlan: no IPv6 routers present
>> [  132.637766] Crypto Speed tests
>> [  132.637766] OCF: testing ...
>> [  133.811467] OCF: 1044 requests of 1500 bytes in 294 jiffies
>> gandalf@wrap:~$
>>
>> Seems the module fails to load. Known issue?
>
> No,  it fails to load by design, but you can see there that is printed
> out a performance number.  You will need to find out you jiffies and
> multiply that out to see the performance.
>
> By default ocf-bench tests sha1/3des,  you will need to modify the
> source to try out AES or something else.  I know it's a complete hack,
> but it is useful if you want raw kenerl performance.
>
> Cheers,
> Davidm
>
> --
> David McCullough,  dav...@se...,   Ph:+61 734352815
> Secure Computing - SnapGear  http://www.uCdot.org   http://www.snapgear.com
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Ocf-linux-users mailing list
> Ocf...@li...
> https://lists.sourceforge.net/lists/listinfo/ocf-linux-users
>

Re: [Ocf-linux-users] No performances improvment with AMD Geode

[David M. <Dav...@se...>]

Jivin "Adam Cécile (Le_Vert)" lays it down ...
> David McCullough a écrit :
> >Jivin "Adam Cécile (Le_Vert)" lays it down ...
> >...
> >  
> >>gandalf@wrap:~$ cat /etc/modules
> >># /etc/modules: kernel modules to load at boot time.
> >>#
> >># This file contains the names of kernel modules that should be loaded
> >># at boot time, one per line. Lines beginning with "#" are ignored.
> >>
> >># Geode WatchDog
> >>geodewdt
> >>
> >># Geode LX AES hardware crypto
> >>geode-aes
> >>geode-rng
> >>crypto_blkcipher
> >>ocf
> >>cryptosoft
> >>cryptodev
> >>
> >># Alix LEDs driver
> >>leds-alix
> >>
> >># Sensors
> >>lm90
> >>
> >>wrap:/home/gandalf# openssl speed -evp aes128 -elapsed
> >>You have chosen to measure elapsed time instead of user CPU time.
> >>To get the most accurate results, try to run this
> >>program when this computer is idle.
> >>Doing aes-128-cbc for 3s on 16 size blocks: 104083 aes-128-cbc's in 3.00s
> >>Doing aes-128-cbc for 3s on 64 size blocks: 101925 aes-128-cbc's in 3.00s
> >>Doing aes-128-cbc for 3s on 256 size blocks: 89677 aes-128-cbc's in 3.00s
> >>Doing aes-128-cbc for 3s on 1024 size blocks: 61529 aes-128-cbc's in 3.00s
> >>Doing aes-128-cbc for 3s on 2048 size blocks: 42862 aes-128-cbc's in 3.00s
> >>OpenSSL 0.9.8g 19 Oct 2007
> >>built on: Wed Jul  9 18:31:21 UTC 2008
> >>options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) 
> >>aes(partial) blowfish(idx)
> >>compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT 
> >>-DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DL_ENDIAN -DTERMIO -O3 
> >>-march=i586 -Wa,--noexecstack -g -Wall -DOPENSSL_BN_ASM_PART_WORDS 
> >>-DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
> >>available timing options: TIMES TIMEB HZ=100 [sysconf value]
> >>timing function used: ftime
> >>The 'numbers' are in 1000s of bytes per second processed.
> >>type             16 bytes     64 bytes    256 bytes   1024 bytes   2048 
> >>bytes
> >>aes-128-cbc        555.11k     2173.68k     7652.44k    21001.90k    
> >>29260.46k
> >>
> >>wrap:/home/gandalf# lsmod | grep cry
> >>crypto_blkcipher       18564  1 geode_aes
> >>wrap:/home/gandalf# lsmod | grep ocf
> >>wrap:/home/gandalf# openssl speed -evp aes128 -elapsed
> >>You have chosen to measure elapsed time instead of user CPU time.
> >>To get the most accurate results, try to run this
> >>program when this computer is idle.
> >>Doing aes-128-cbc for 3s on 16 size blocks: 895899 aes-128-cbc's in 3.00s
> >>Doing aes-128-cbc for 3s on 64 size blocks: 324390 aes-128-cbc's in 3.00s
> >>Doing aes-128-cbc for 3s on 256 size blocks: 92243 aes-128-cbc's in 3.00s
> >>Doing aes-128-cbc for 3s on 1024 size blocks: 23823 aes-128-cbc's in 3.00s
> >>Doing aes-128-cbc for 3s on 2048 size blocks: 11998 aes-128-cbc's in 3.00s
> >>OpenSSL 0.9.8g 19 Oct 2007
> >>built on: Wed Jul  9 18:31:21 UTC 2008
> >>options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) 
> >>aes(partial) blowfish(idx)
> >>compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT 
> >>-DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DL_ENDIAN -DTERMIO -O3 
> >>-march=i586 -Wa,--noexecstack -g -Wall -DOPENSSL_BN_ASM_PART_WORDS 
> >>-DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
> >>available timing options: TIMES TIMEB HZ=100 [sysconf value]
> >>timing function used: ftime
> >>The 'numbers' are in 1000s of bytes per second processed.
> >>type             16 bytes     64 bytes    256 bytes   1024 bytes   2048 
> >>bytes
> >>aes-128-cbc       4778.13k     6920.32k     7871.40k     8131.58k     
> >>8190.63k
> >>
> >>Okay there's performance difference when I unload all ocf/cryptodev 
> >>kernel modules. But are you sure it comes from hardware ? It may just 
> >>come from the fact that ocf software perform better than the standard 
> >>linux crypto stack. What's your mind about this ?
> >>    
> >
> >If ocf is using software crypto it can never (on a single crypto stream)
> >go faster than openssl (or kernel crypto) without ocf.  It's just not
> >possible since they are all using basically the same crypto code on the
> >same speed CPU.
> >
> >So yes,  I am sure you are doing HW crypto using OCF+cryptosoft and geode.
> >
> >It would go even faster if you ran it from in the kernel.  This is what
> >the ocf-bench driver does if you are interested:
> >
> >	modprobe ocf-bench
> >	dmesg
> >
> >Cheers,
> >Davidm
> >  
> Hello,
> 
> I've just rebuild my kernel with ocf-bench. Here is what happens:
> gandalf@wrap:~$ sudo modprobe ocf-bench
> [sudo] password for root:
> FATAL: Error inserting ocf_bench 
> (/lib/modules/2.6.25-2-alix/kernel/crypto/ocf/o                             
> cf-bench.ko): Invalid argument
> gandalf@wrap:~$ dmesg | tail
> [   44.840932] wan: no IPv6 routers present
> [   61.510480] ip6_tables: (C) 2000-2006 Netfilter Core Team
> [   66.773388] warning: `named' uses 32-bit capabilities (legacy support 
> in use)
> [   74.301323] tun: Universal TUN/TAP device driver, 1.6
> [   74.301346] tun: (C) 1999-2004 Max Krasnyansky <ma...@qu...>
> [   74.307817] tun0: Disabled Privacy Extensions
> [   82.660103] wlan: no IPv6 routers present
> [  132.637766] Crypto Speed tests
> [  132.637766] OCF: testing ...
> [  133.811467] OCF: 1044 requests of 1500 bytes in 294 jiffies
> gandalf@wrap:~$
> 
> Seems the module fails to load. Known issue?

No,  it fails to load by design, but you can see there that is printed
out a performance number.  You will need to find out you jiffies and
multiply that out to see the performance.

By default ocf-bench tests sha1/3des,  you will need to modify the
source to try out AES or something else.  I know it's a complete hack,
but it is useful if you want raw kenerl performance.

Cheers,
Davidm

-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org   http://www.snapgear.com

Re: [Ocf-linux-users] OpenVPN Speed improvement

[Andreas S. <a.s...@go...>]

Hi,

I found out that the connection is also very slow while using no
encryption. I have to investigate this problem further.

Best
Andreas

On Thu, Jul 10, 2008 at 1:02 AM, David McCullough
<Dav...@se...> wrote:
>
> Jivin Andreas Steinel lays it down ...
>> Hi all,
>>
>> One month ago, Nikola Ciprich asked if it's possible to enhance the
>> throughput of openVPN connections via OCF. Are there any new
>> information of known tweaks for this problem?
>>
>> I'd the problem too. Maybe it could help if someone has any idea to
>> implement it in openvpn an can explain it here.
>
> I haven't looked at it,  but does OpenVPN use openssl for it's crypto ?
> If it does just apply the ocf patch to your openssl dist before building
> and add te hconfigure options --with-cryptodev to enable OCF support.
>
> If OpenVPN  doesn't use OpenSSL then it should be easy to look at the
> openswan (pluto) patch or the cryptotest tool to see how to call into
> cryptodev to make things faster,
>
> Cheers,
> Davidm
>
> --
> David McCullough,  dav...@se...,   Ph:+61 734352815
> Secure Computing - SnapGear  http://www.uCdot.org   http://www.snapgear.com
>

Re: [Ocf-linux-users] No performances improvment with AMD Geode

[Adam C. (Le_Vert) <ga...@le...>]

David McCullough a écrit :
> Jivin "Adam Cécile (Le_Vert)" lays it down ...
> ...
>   
>> gandalf@wrap:~$ cat /etc/modules
>> # /etc/modules: kernel modules to load at boot time.
>> #
>> # This file contains the names of kernel modules that should be loaded
>> # at boot time, one per line. Lines beginning with "#" are ignored.
>>
>> # Geode WatchDog
>> geodewdt
>>
>> # Geode LX AES hardware crypto
>> geode-aes
>> geode-rng
>> crypto_blkcipher
>> ocf
>> cryptosoft
>> cryptodev
>>
>> # Alix LEDs driver
>> leds-alix
>>
>> # Sensors
>> lm90
>>
>> wrap:/home/gandalf# openssl speed -evp aes128 -elapsed
>> You have chosen to measure elapsed time instead of user CPU time.
>> To get the most accurate results, try to run this
>> program when this computer is idle.
>> Doing aes-128-cbc for 3s on 16 size blocks: 104083 aes-128-cbc's in 3.00s
>> Doing aes-128-cbc for 3s on 64 size blocks: 101925 aes-128-cbc's in 3.00s
>> Doing aes-128-cbc for 3s on 256 size blocks: 89677 aes-128-cbc's in 3.00s
>> Doing aes-128-cbc for 3s on 1024 size blocks: 61529 aes-128-cbc's in 3.00s
>> Doing aes-128-cbc for 3s on 2048 size blocks: 42862 aes-128-cbc's in 3.00s
>> OpenSSL 0.9.8g 19 Oct 2007
>> built on: Wed Jul  9 18:31:21 UTC 2008
>> options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) 
>> aes(partial) blowfish(idx)
>> compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT 
>> -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DL_ENDIAN -DTERMIO -O3 
>> -march=i586 -Wa,--noexecstack -g -Wall -DOPENSSL_BN_ASM_PART_WORDS 
>> -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
>> available timing options: TIMES TIMEB HZ=100 [sysconf value]
>> timing function used: ftime
>> The 'numbers' are in 1000s of bytes per second processed.
>> type             16 bytes     64 bytes    256 bytes   1024 bytes   2048 
>> bytes
>> aes-128-cbc        555.11k     2173.68k     7652.44k    21001.90k    
>> 29260.46k
>>
>> wrap:/home/gandalf# lsmod | grep cry
>> crypto_blkcipher       18564  1 geode_aes
>> wrap:/home/gandalf# lsmod | grep ocf
>> wrap:/home/gandalf# openssl speed -evp aes128 -elapsed
>> You have chosen to measure elapsed time instead of user CPU time.
>> To get the most accurate results, try to run this
>> program when this computer is idle.
>> Doing aes-128-cbc for 3s on 16 size blocks: 895899 aes-128-cbc's in 3.00s
>> Doing aes-128-cbc for 3s on 64 size blocks: 324390 aes-128-cbc's in 3.00s
>> Doing aes-128-cbc for 3s on 256 size blocks: 92243 aes-128-cbc's in 3.00s
>> Doing aes-128-cbc for 3s on 1024 size blocks: 23823 aes-128-cbc's in 3.00s
>> Doing aes-128-cbc for 3s on 2048 size blocks: 11998 aes-128-cbc's in 3.00s
>> OpenSSL 0.9.8g 19 Oct 2007
>> built on: Wed Jul  9 18:31:21 UTC 2008
>> options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) 
>> aes(partial) blowfish(idx)
>> compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT 
>> -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DL_ENDIAN -DTERMIO -O3 
>> -march=i586 -Wa,--noexecstack -g -Wall -DOPENSSL_BN_ASM_PART_WORDS 
>> -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
>> available timing options: TIMES TIMEB HZ=100 [sysconf value]
>> timing function used: ftime
>> The 'numbers' are in 1000s of bytes per second processed.
>> type             16 bytes     64 bytes    256 bytes   1024 bytes   2048 
>> bytes
>> aes-128-cbc       4778.13k     6920.32k     7871.40k     8131.58k     
>> 8190.63k
>>
>> Okay there's performance difference when I unload all ocf/cryptodev 
>> kernel modules. But are you sure it comes from hardware ? It may just 
>> come from the fact that ocf software perform better than the standard 
>> linux crypto stack. What's your mind about this ?
>>     
>
> If ocf is using software crypto it can never (on a single crypto stream)
> go faster than openssl (or kernel crypto) without ocf.  It's just not
> possible since they are all using basically the same crypto code on the
> same speed CPU.
>
> So yes,  I am sure you are doing HW crypto using OCF+cryptosoft and geode.
>
> It would go even faster if you ran it from in the kernel.  This is what
> the ocf-bench driver does if you are interested:
>
> 	modprobe ocf-bench
> 	dmesg
>
> Cheers,
> Davidm
>   
Hello,

I've just rebuild my kernel with ocf-bench. Here is what happens:
gandalf@wrap:~$ sudo modprobe ocf-bench
[sudo] password for root:
FATAL: Error inserting ocf_bench 
(/lib/modules/2.6.25-2-alix/kernel/crypto/ocf/o                                                                            
cf-bench.ko): Invalid argument
gandalf@wrap:~$ dmesg | tail
[   44.840932] wan: no IPv6 routers present
[   61.510480] ip6_tables: (C) 2000-2006 Netfilter Core Team
[   66.773388] warning: `named' uses 32-bit capabilities (legacy support 
in use)
[   74.301323] tun: Universal TUN/TAP device driver, 1.6
[   74.301346] tun: (C) 1999-2004 Max Krasnyansky <ma...@qu...>
[   74.307817] tun0: Disabled Privacy Extensions
[   82.660103] wlan: no IPv6 routers present
[  132.637766] Crypto Speed tests
[  132.637766] OCF: testing ...
[  133.811467] OCF: 1044 requests of 1500 bytes in 294 jiffies
gandalf@wrap:~$

Seems the module fails to load. Known issue?

Regards, Adam.

Re: [Ocf-linux-users] Regarding ocf for ipsec

[David M. <Dav...@se...>]

Jivin Manish RATHI lays it down ...
> Hi,
> I've applied the patch.
>  As such there is no change in ipsec files in kernel networking stack. 

Thats correct because the linux NETKEY stack does not use OCF and there
is no patch to make this work.

If you want accelerated IPSEC that uses OCF you need to use openswan
and the openswan KLIPS kernel stack,  not the linux NETKEY kernel stack.

> Can you tell me name of files which tell the linux kernel so that it uses
> OCF instead of linux kernel crypto framework?

Read about openswan here:

	www.openswan.org

The latest version of openswan that uses OCF is:

	http://www.openswan.org/download/development/openswan-2.6.16dr4.tar.gz

or there is the older stable 2.4 series,

Cheers,
Davidm

> -----Original Message-----
> From: David McCullough [mailto:Dav...@se...] 
> Sent: Thursday, July 10, 2008 4:17 PM
> To: Manish RATHI
> Cc: ocf...@li...
> Subject: Re: [Ocf-linux-users] Regarding ocf for ipsec
> 
> 
> Jivin Manish RATHI lays it down ...
> > Hi,
> > Patch I found for linux KLIPS Openswan doesn't look to be applicable 
> > to latest 2.6.24 kernel.
> 
> Go to:
> 	http://sourceforge.net/project/showfiles.php?group_id=133575
> 
> and download
> 
>    	ocf-linux-26-20080704.patch.gz
> 
> take a stock linux-2.6.24 (or 25) and extract:
> 
> 	cd linux-2.6.24
> 	gunzip < ocf-linux-26-20080704.patch.gz | patch -p1
> 
> The previous OCF release (20071215) has a patch for 2.6.23.
> Either way,  I know it's supported because I am running it :-)
> 
> > It's big change and I am not sure about its stability.
> 
> The patch is big because it includes all of OCF so that you do not need to
> do anything else.  I have had some reports that you may need to fix a couple
> of things after applying the patch but I have no details to help you with on
> that.
> 
> > Has anybody used it over 2.6.24?
> 
> Anyone other than me :-)
> 
> > Can I use crptodev with linux kernel crypto framework so that I use
> > openssl+cryptodev + linux crypto? Is there any patch available?
> 
> No and not that I know of.
> 
> > I am still not able to appreciate why linux kernel crypto framework 
> > not able to provide async APIs as OCF is providing.
> 
> Read the linux-crypto or the older cryptodev mailing list archives,  it may
> help,
> 
> Cheers.
> Davidm
> 
> > -----Original Message-----
> > From: David McCullough [mailto:Dav...@se...]
> > Sent: Thursday, July 10, 2008 4:41 AM
> > To: Manish RATHI
> > Cc: ocf...@li...
> > Subject: Re: [Ocf-linux-users] Regarding ocf for ipsec
> > 
> > 
> > Jivin Manish RATHI lays it down ...
> > > Hi,
> > >  ipsec in vannila linux kernel uses linux kernel crypto not OCF
> framework?
> > 
> > yes.
> > 
> > > I am using OCF driver  for crypto acceleration to be used with 
> > > openssl
> > engine.
> > > 
> > > Currently ipsec uses linux kernel crypto framework. So I've to write 
> > > 2 drivers
> > 
> > You could use the openswan KLIPS stack in the kernel instead.
> > 
> > > 1) kernel crypto driver
> > > 2) OCF driver
> > > 
> > > I'd like to use single driver that can be used with OpenSSL/OCF and 
> > > Linux
> > kernel crypto.
> > > 
> > > Is there any stable patch available for ipsec in latest linux kernel 
> > > so
> > that it uses OCF?
> > 
> > No.  The linux kernel is doing it's own async crypto but I am not sure 
> > which kernel is is/will appear in and how stable it is.
> > 
> > > Why OCF is not used in linux kernel for ipsec?
> > 
> > One reason is licensing (OCF is BSD license).
> > 
> > > I've read that current
> > > ipsec doesn't uses Bottom half so async API framework such as OCF is 
> > > not required.  Is it correct?
> > 
> > An async api is required,  but previously the stack counld not handle it.
> > Work is being done in the space by the linux crypto guys.
> > 
> > > What are the pros and cons of using OCF with ipsec? 
> > 
> > It goes faster,  you have to patch your kernel,
> > 
> > Cheers,
> > Davidm
> > 
> > -- 
> > David McCullough,  dav...@se...,   Ph:+61
> 734352815
> > Secure Computing - SnapGear  http://www.uCdot.org
> http://www.snapgear.com
> > 
> 
> -- 
> David McCullough,  dav...@se...,   Ph:+61 734352815
> Secure Computing - SnapGear  http://www.uCdot.org   http://www.snapgear.com
> 

-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org   http://www.snapgear.com

Re: [Ocf-linux-users] Regarding ocf for ipsec

[Manish R. <man...@st...>]

Hi,
I've applied the patch.
 As such there is no change in ipsec files in kernel networking stack. 

Can you tell me name of files which tell the linux kernel so that it uses
OCF instead of linux kernel crypto framework?

Thanks
Regards
Manish

-----Original Message-----
From: David McCullough [mailto:Dav...@se...] 
Sent: Thursday, July 10, 2008 4:17 PM
To: Manish RATHI
Cc: ocf...@li...
Subject: Re: [Ocf-linux-users] Regarding ocf for ipsec


Jivin Manish RATHI lays it down ...
> Hi,
> Patch I found for linux KLIPS Openswan doesn't look to be applicable 
> to latest 2.6.24 kernel.

Go to:
	http://sourceforge.net/project/showfiles.php?group_id=133575

and download

   	ocf-linux-26-20080704.patch.gz

take a stock linux-2.6.24 (or 25) and extract:

	cd linux-2.6.24
	gunzip < ocf-linux-26-20080704.patch.gz | patch -p1

The previous OCF release (20071215) has a patch for 2.6.23.
Either way,  I know it's supported because I am running it :-)

> It's big change and I am not sure about its stability.

The patch is big because it includes all of OCF so that you do not need to
do anything else.  I have had some reports that you may need to fix a couple
of things after applying the patch but I have no details to help you with on
that.

> Has anybody used it over 2.6.24?

Anyone other than me :-)

> Can I use crptodev with linux kernel crypto framework so that I use
> openssl+cryptodev + linux crypto? Is there any patch available?

No and not that I know of.

> I am still not able to appreciate why linux kernel crypto framework 
> not able to provide async APIs as OCF is providing.

Read the linux-crypto or the older cryptodev mailing list archives,  it may
help,

Cheers.
Davidm

> -----Original Message-----
> From: David McCullough [mailto:Dav...@se...]
> Sent: Thursday, July 10, 2008 4:41 AM
> To: Manish RATHI
> Cc: ocf...@li...
> Subject: Re: [Ocf-linux-users] Regarding ocf for ipsec
> 
> 
> Jivin Manish RATHI lays it down ...
> > Hi,
> >  ipsec in vannila linux kernel uses linux kernel crypto not OCF
framework?
> 
> yes.
> 
> > I am using OCF driver  for crypto acceleration to be used with 
> > openssl
> engine.
> > 
> > Currently ipsec uses linux kernel crypto framework. So I've to write 
> > 2 drivers
> 
> You could use the openswan KLIPS stack in the kernel instead.
> 
> > 1) kernel crypto driver
> > 2) OCF driver
> > 
> > I'd like to use single driver that can be used with OpenSSL/OCF and 
> > Linux
> kernel crypto.
> > 
> > Is there any stable patch available for ipsec in latest linux kernel 
> > so
> that it uses OCF?
> 
> No.  The linux kernel is doing it's own async crypto but I am not sure 
> which kernel is is/will appear in and how stable it is.
> 
> > Why OCF is not used in linux kernel for ipsec?
> 
> One reason is licensing (OCF is BSD license).
> 
> > I've read that current
> > ipsec doesn't uses Bottom half so async API framework such as OCF is 
> > not required.  Is it correct?
> 
> An async api is required,  but previously the stack counld not handle it.
> Work is being done in the space by the linux crypto guys.
> 
> > What are the pros and cons of using OCF with ipsec? 
> 
> It goes faster,  you have to patch your kernel,
> 
> Cheers,
> Davidm
> 
> -- 
> David McCullough,  dav...@se...,   Ph:+61
734352815
> Secure Computing - SnapGear  http://www.uCdot.org
http://www.snapgear.com
> 

-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org   http://www.snapgear.com

Re: [Ocf-linux-users] Regarding ocf for ipsec

[David M. <Dav...@se...>]

Jivin Manish RATHI lays it down ...
> Hi,
> Patch I found for linux KLIPS Openswan doesn't look to be applicable to
> latest 2.6.24 kernel.

Go to:
	http://sourceforge.net/project/showfiles.php?group_id=133575

and download

   	ocf-linux-26-20080704.patch.gz

take a stock linux-2.6.24 (or 25) and extract:

	cd linux-2.6.24
	gunzip < ocf-linux-26-20080704.patch.gz | patch -p1

The previous OCF release (20071215) has a patch for 2.6.23.
Either way,  I know it's supported because I am running it :-)

> It's big change and I am not sure about its stability.

The patch is big because it includes all of OCF so that you do not need
to do anything else.  I have had some reports that you may need to fix a
couple of things after applying the patch but I have no details to help
you with on that.

> Has anybody used it over 2.6.24?

Anyone other than me :-)

> Can I use crptodev with linux kernel crypto framework so that I use
> openssl+cryptodev + linux crypto? Is there any patch available?

No and not that I know of.

> I am still not able to appreciate why linux kernel crypto framework not able
> to provide async APIs as OCF is providing.

Read the linux-crypto or the older cryptodev mailing list archives,  it
may help,

Cheers.
Davidm

> -----Original Message-----
> From: David McCullough [mailto:Dav...@se...] 
> Sent: Thursday, July 10, 2008 4:41 AM
> To: Manish RATHI
> Cc: ocf...@li...
> Subject: Re: [Ocf-linux-users] Regarding ocf for ipsec
> 
> 
> Jivin Manish RATHI lays it down ...
> > Hi,
> >  ipsec in vannila linux kernel uses linux kernel crypto not OCF framework?
> 
> yes.
> 
> > I am using OCF driver  for crypto acceleration to be used with openssl
> engine.
> > 
> > Currently ipsec uses linux kernel crypto framework. So I've to write 2 
> > drivers
> 
> You could use the openswan KLIPS stack in the kernel instead.
> 
> > 1) kernel crypto driver
> > 2) OCF driver
> > 
> > I'd like to use single driver that can be used with OpenSSL/OCF and Linux
> kernel crypto.
> > 
> > Is there any stable patch available for ipsec in latest linux kernel so
> that it uses OCF?
> 
> No.  The linux kernel is doing it's own async crypto but I am not sure which
> kernel is is/will appear in and how stable it is.
> 
> > Why OCF is not used in linux kernel for ipsec?
> 
> One reason is licensing (OCF is BSD license).
> 
> > I've read that current
> > ipsec doesn't uses Bottom half so async API framework such as OCF is 
> > not required.  Is it correct?
> 
> An async api is required,  but previously the stack counld not handle it.
> Work is being done in the space by the linux crypto guys.
> 
> > What are the pros and cons of using OCF with ipsec? 
> 
> It goes faster,  you have to patch your kernel,
> 
> Cheers,
> Davidm
> 
> -- 
> David McCullough,  dav...@se...,   Ph:+61 734352815
> Secure Computing - SnapGear  http://www.uCdot.org   http://www.snapgear.com
> 

-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org   http://www.snapgear.com

Re: [Ocf-linux-users] No performances improvment with AMD Geode

[David M. <Dav...@se...>]

Jivin "Adam Cécile (Le_Vert)" lays it down ...
...
> gandalf@wrap:~$ cat /etc/modules
> # /etc/modules: kernel modules to load at boot time.
> #
> # This file contains the names of kernel modules that should be loaded
> # at boot time, one per line. Lines beginning with "#" are ignored.
> 
> # Geode WatchDog
> geodewdt
> 
> # Geode LX AES hardware crypto
> geode-aes
> geode-rng
> crypto_blkcipher
> ocf
> cryptosoft
> cryptodev
> 
> # Alix LEDs driver
> leds-alix
> 
> # Sensors
> lm90
> 
> wrap:/home/gandalf# openssl speed -evp aes128 -elapsed
> You have chosen to measure elapsed time instead of user CPU time.
> To get the most accurate results, try to run this
> program when this computer is idle.
> Doing aes-128-cbc for 3s on 16 size blocks: 104083 aes-128-cbc's in 3.00s
> Doing aes-128-cbc for 3s on 64 size blocks: 101925 aes-128-cbc's in 3.00s
> Doing aes-128-cbc for 3s on 256 size blocks: 89677 aes-128-cbc's in 3.00s
> Doing aes-128-cbc for 3s on 1024 size blocks: 61529 aes-128-cbc's in 3.00s
> Doing aes-128-cbc for 3s on 2048 size blocks: 42862 aes-128-cbc's in 3.00s
> OpenSSL 0.9.8g 19 Oct 2007
> built on: Wed Jul  9 18:31:21 UTC 2008
> options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) 
> aes(partial) blowfish(idx)
> compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT 
> -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DL_ENDIAN -DTERMIO -O3 
> -march=i586 -Wa,--noexecstack -g -Wall -DOPENSSL_BN_ASM_PART_WORDS 
> -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
> available timing options: TIMES TIMEB HZ=100 [sysconf value]
> timing function used: ftime
> The 'numbers' are in 1000s of bytes per second processed.
> type             16 bytes     64 bytes    256 bytes   1024 bytes   2048 
> bytes
> aes-128-cbc        555.11k     2173.68k     7652.44k    21001.90k    
> 29260.46k
> 
> wrap:/home/gandalf# lsmod | grep cry
> crypto_blkcipher       18564  1 geode_aes
> wrap:/home/gandalf# lsmod | grep ocf
> wrap:/home/gandalf# openssl speed -evp aes128 -elapsed
> You have chosen to measure elapsed time instead of user CPU time.
> To get the most accurate results, try to run this
> program when this computer is idle.
> Doing aes-128-cbc for 3s on 16 size blocks: 895899 aes-128-cbc's in 3.00s
> Doing aes-128-cbc for 3s on 64 size blocks: 324390 aes-128-cbc's in 3.00s
> Doing aes-128-cbc for 3s on 256 size blocks: 92243 aes-128-cbc's in 3.00s
> Doing aes-128-cbc for 3s on 1024 size blocks: 23823 aes-128-cbc's in 3.00s
> Doing aes-128-cbc for 3s on 2048 size blocks: 11998 aes-128-cbc's in 3.00s
> OpenSSL 0.9.8g 19 Oct 2007
> built on: Wed Jul  9 18:31:21 UTC 2008
> options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) 
> aes(partial) blowfish(idx)
> compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT 
> -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DL_ENDIAN -DTERMIO -O3 
> -march=i586 -Wa,--noexecstack -g -Wall -DOPENSSL_BN_ASM_PART_WORDS 
> -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
> available timing options: TIMES TIMEB HZ=100 [sysconf value]
> timing function used: ftime
> The 'numbers' are in 1000s of bytes per second processed.
> type             16 bytes     64 bytes    256 bytes   1024 bytes   2048 
> bytes
> aes-128-cbc       4778.13k     6920.32k     7871.40k     8131.58k     
> 8190.63k
> 
> Okay there's performance difference when I unload all ocf/cryptodev 
> kernel modules. But are you sure it comes from hardware ? It may just 
> come from the fact that ocf software perform better than the standard 
> linux crypto stack. What's your mind about this ?

If ocf is using software crypto it can never (on a single crypto stream)
go faster than openssl (or kernel crypto) without ocf.  It's just not
possible since they are all using basically the same crypto code on the
same speed CPU.

So yes,  I am sure you are doing HW crypto using OCF+cryptosoft and geode.

It would go even faster if you ran it from in the kernel.  This is what
the ocf-bench driver does if you are interested:

	modprobe ocf-bench
	dmesg

Cheers,
Davidm

-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org   http://www.snapgear.com

Re: [Ocf-linux-users] No performances improvment with AMD Geode

[Adam C. (Le_Vert) <ga...@le...>]

David McCullough a écrit :
> Jivin "Adam Cécile (Le_Vert)" lays it down ...
>   
>> David McCullough a écrit :
>>     
>>> Jivin "Adam Cécile (Le_Vert)" lays it down ...
>>>   
>>>       
>>>> Daniel Mueller a écrit :
>>>>     
>>>>         
>>>>> On Mon, 02 Jun 2008 17:25:23 +0200 Adam Cécile wrote:
>>>>>
>>>>> I do not own a AMD Geode but..
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>>>> Loaded kernel modules:
>>>>>> gandalf@alix:~$ lsmod | grep -e cry -e oc
>>>>>> cryptodev              13988  3
>>>>>> crypto_null             2624  0
>>>>>> cryptosoft             12136  0
>>>>>> ocf                    28984  2 cryptodev,cryptosoft
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> .. you need to load the geode-aes module as well. You can find it in
>>>>> your kernel configuration.
>>>>>
>>>>> Cryptographic API  ---> 
>>>>>  [*]   Hardware crypto devices  --->
>>>>>   <M>   Support for the Geode LX AES engine
>>>>>
>>>>> Try to load the modules in the following order:
>>>>> geode-aes.ko
>>>>> ocf.ko
>>>>> cryptosoft.ko
>>>>> cryptodev.ko 
>>>>>
>>>>> bye,
>>>>> danm
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>> gandalf@alix:~$ cat /etc/modules
>>>> # /etc/modules: kernel modules to load at boot time.
>>>> #
>>>> # This file contains the names of kernel modules that should be loaded
>>>> # at boot time, one per line. Lines beginning with "#" are ignored.
>>>>
>>>> # Geode WatchDog
>>>> geodewdt
>>>>
>>>> # Geode LX AES hardware crypto
>>>> geode-aes
>>>> geode-rng
>>>> ocf
>>>> cryptosoft
>>>> cryptodev
>>>>
>>>> # Alix LEDs driver
>>>> leds-alix
>>>>
>>>> # Sensors
>>>> lm90
>>>>
>>>> It's already loaded. Any other idea ? ;)
>>>>     
>>>>         
>>> Did you check that with a "lsmod" to be sure ?
>>>
>>> Thanks,
>>> Davidm
>>>
>>>   
>>>       
>> Hello,
>>
>> I've updated to debian's kernel 2.6.25-3-686 + latest ocf patch and I
>> still don't see any performance improvement.
>>     
>
>
> Have a look for emails by "Andreas Steinel" just recently , he seems to
> have got it working,  might be some clues.
> More below.
>
>
>   
>> gandalf@wrap:~$ lsmod | grep -e cry -e oc
>> cryptodev              13572  3
>> crypto_null             3392  0
>> cryptosoft             11624  0
>> ocf                    29176  2 cryptodev,cryptosoft
>> crypto_blkcipher       18564  4 crypto_null,ecb,cbc,geode_aes
>> dock                   10320  1 libata
>>     
>
> Make sure you load crypto_blkcipher before you load ocf.
>
>   
>> gandalf@wrap:~$ ls -lah /dev/crypto
>> crw-rw-rw- 1 root root 10, 70 Jan  1  2000 /dev/crypto
>>
>> gandalf@wrap:~$ openssl engine
>> (cryptodev) BSD cryptodev engine
>> (padlock) VIA PadLock (no-RNG, no-ACE)
>> (dynamic) Dynamic engine loading support
>>
>> gandalf@wrap:~$ openssl speed -evp aes128 -elapsed
>> You have chosen to measure elapsed time instead of user CPU time.
>> To get the most accurate results, try to run this
>> program when this computer is idle.
>> Doing aes-128-cbc for 3s on 16 size blocks: 123525 aes-128-cbc's in 3.00s
>> Doing aes-128-cbc for 3s on 64 size blocks: 119105 aes-128-cbc's in 3.00s
>> Doing aes-128-cbc for 3s on 256 size blocks: 103091 aes-128-cbc's in 3.00s
>> Doing aes-128-cbc for 3s on 1024 size blocks: 68212 aes-128-cbc's in 3.00s
>> Doing aes-128-cbc for 3s on 2048 size blocks: 46401 aes-128-cbc's in 3.00s
>> OpenSSL 0.9.8g 19 Oct 2007
>> built on: Mon Jun  2 14:52:51 UTC 2008
>> options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long)
>> aes(partial) blowfish(idx)
>> compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT
>> -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DL_ENDIAN -DTERMIO -O3
>> -march=i586 -Wa,--noexecstack -g -Wall -DOPENSSL_BN_ASM_PART_WORDS
>> -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
>> available timing options: TIMES TIMEB HZ=100 [sysconf value]
>> timing function used: ftime
>> The 'numbers' are in 1000s of bytes per second processed.
>> type             16 bytes     64 bytes    256 bytes   1024 bytes   2048
>> bytes
>> aes-128-cbc        658.80k     2540.91k     8797.10k    23283.03k   
>> 31676.42k
>>     
>
>
> Ok,  this looks like you are using OCF  for crypto,  it is easy to tell
> because the small packets do not get the same total throughput as the
> large packets.
>
> If you "rmmod cryptodev" then run the test again it should confirm this.
>
>
>   
>> gandalf@wrap:~$ openssl speed -evp aes128 -elapsed -engine cryptodev
>> engine "cryptodev" set.
>> You have chosen to measure elapsed time instead of user CPU time.
>> To get the most accurate results, try to run this
>> program when this computer is idle.
>> Doing aes-128-cbc for 3s on 16 size blocks: 123212 aes-128-cbc's in 3.00s
>> Doing aes-128-cbc for 3s on 64 size blocks: 119413 aes-128-cbc's in 3.00s
>> Doing aes-128-cbc for 3s on 256 size blocks: 103493 aes-128-cbc's in 3.00s
>> Doing aes-128-cbc for 3s on 1024 size blocks: 67906 aes-128-cbc's in 3.00s
>> Doing aes-128-cbc for 3s on 2048 size blocks: 46018 aes-128-cbc's in 3.00s
>> OpenSSL 0.9.8g 19 Oct 2007
>> built on: Mon Jun  2 14:52:51 UTC 2008
>> options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long)
>> aes(partial) blowfish(idx)
>> compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT
>> -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DL_ENDIAN -DTERMIO -O3
>> -march=i586 -Wa,--noexecstack -g -Wall -DOPENSSL_BN_ASM_PART_WORDS
>> -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
>> available timing options: TIMES TIMEB HZ=100 [sysconf value]
>> timing function used: ftime
>> The 'numbers' are in 1000s of bytes per second processed.
>> type             16 bytes     64 bytes    256 bytes   1024 bytes   2048
>> bytes
>> aes-128-cbc        657.13k     2546.63k     8831.40k    23178.58k   
>> 31414.95k
>>     
>
> These numbers at the same as above.  The reason for that is openssl will
> use ocf by default if it is enabled.  The best way to check is to remove
> the cryptodev driver and see what the performance is.
>
> Either way,  you are getting 31414.95k bytes of AES throughput.  Thats
> around 250Mbits/s using 2k packets.  Are you sure that is not fast enough ?
>
> Check your numbers with cryptodev unloaded to know for sure.
>
>   
>> Only OpenSSL hasn't been rebuilt with latest OCF patch but I'll do asap.
>> Any pointers would be greatly appreciated (maybe my bench commands are
>> just wrong ?).
>>     
>
> No need to do that,  the patch hasn't changed since the last release (at
> least I don't recall any changes ;-)
>
> Cheers,
> Davidm
>
>   
gandalf@wrap:~$ cat /etc/modules
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.

# Geode WatchDog
geodewdt

# Geode LX AES hardware crypto
geode-aes
geode-rng
crypto_blkcipher
ocf
cryptosoft
cryptodev

# Alix LEDs driver
leds-alix

# Sensors
lm90

wrap:/home/gandalf# openssl speed -evp aes128 -elapsed
You have chosen to measure elapsed time instead of user CPU time.
To get the most accurate results, try to run this
program when this computer is idle.
Doing aes-128-cbc for 3s on 16 size blocks: 104083 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 101925 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 89677 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 61529 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 2048 size blocks: 42862 aes-128-cbc's in 3.00s
OpenSSL 0.9.8g 19 Oct 2007
built on: Wed Jul  9 18:31:21 UTC 2008
options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) 
aes(partial) blowfish(idx)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT 
-DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DL_ENDIAN -DTERMIO -O3 
-march=i586 -Wa,--noexecstack -g -Wall -DOPENSSL_BN_ASM_PART_WORDS 
-DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: ftime
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   2048 
bytes
aes-128-cbc        555.11k     2173.68k     7652.44k    21001.90k    
29260.46k

wrap:/home/gandalf# lsmod | grep cry
crypto_blkcipher       18564  1 geode_aes
wrap:/home/gandalf# lsmod | grep ocf
wrap:/home/gandalf# openssl speed -evp aes128 -elapsed
You have chosen to measure elapsed time instead of user CPU time.
To get the most accurate results, try to run this
program when this computer is idle.
Doing aes-128-cbc for 3s on 16 size blocks: 895899 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 324390 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 92243 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 23823 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 2048 size blocks: 11998 aes-128-cbc's in 3.00s
OpenSSL 0.9.8g 19 Oct 2007
built on: Wed Jul  9 18:31:21 UTC 2008
options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) 
aes(partial) blowfish(idx)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT 
-DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DL_ENDIAN -DTERMIO -O3 
-march=i586 -Wa,--noexecstack -g -Wall -DOPENSSL_BN_ASM_PART_WORDS 
-DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: ftime
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   2048 
bytes
aes-128-cbc       4778.13k     6920.32k     7871.40k     8131.58k     
8190.63k

Okay there's performance difference when I unload all ocf/cryptodev 
kernel modules. But are you sure it comes from hardware ? It may just 
come from the fact that ocf software perform better than the standard 
linux crypto stack. What's your mind about this ?

Thanks in advance,

Regards, Adam.

Re: [Ocf-linux-users] Regarding ocf for ipsec

[Manish R. <man...@st...>]

Hi,
Patch I found for linux KLIPS Openswan doesn't look to be applicable to
latest 2.6.24 kernel. It's big change and I am not sure about its stability.
Has anybody used it over 2.6.24?

Can I use crptodev with linux kernel crypto framework so that I use
openssl+cryptodev + linux crypto? Is there any patch available?

I am still not able to appreciate why linux kernel crypto framework not able
to provide async APIs as OCF is providing.

Thanks
Regards
Manish

 

-----Original Message-----
From: David McCullough [mailto:Dav...@se...] 
Sent: Thursday, July 10, 2008 4:41 AM
To: Manish RATHI
Cc: ocf...@li...
Subject: Re: [Ocf-linux-users] Regarding ocf for ipsec


Jivin Manish RATHI lays it down ...
> Hi,
>  ipsec in vannila linux kernel uses linux kernel crypto not OCF framework?

yes.

> I am using OCF driver  for crypto acceleration to be used with openssl
engine.
> 
> Currently ipsec uses linux kernel crypto framework. So I've to write 2 
> drivers

You could use the openswan KLIPS stack in the kernel instead.

> 1) kernel crypto driver
> 2) OCF driver
> 
> I'd like to use single driver that can be used with OpenSSL/OCF and Linux
kernel crypto.
> 
> Is there any stable patch available for ipsec in latest linux kernel so
that it uses OCF?

No.  The linux kernel is doing it's own async crypto but I am not sure which
kernel is is/will appear in and how stable it is.

> Why OCF is not used in linux kernel for ipsec?

One reason is licensing (OCF is BSD license).

> I've read that current
> ipsec doesn't uses Bottom half so async API framework such as OCF is 
> not required.  Is it correct?

An async api is required,  but previously the stack counld not handle it.
Work is being done in the space by the linux crypto guys.

> What are the pros and cons of using OCF with ipsec? 

It goes faster,  you have to patch your kernel,

Cheers,
Davidm

-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org   http://www.snapgear.com

Re: [Ocf-linux-users] No performances improvment with AMD Geode

[David M. <Dav...@se...>]

Jivin "Adam Cécile (Le_Vert)" lays it down ...
> David McCullough a écrit :
> > Jivin "Adam Cécile (Le_Vert)" lays it down ...
> >   
> >> Daniel Mueller a écrit :
> >>     
> >>> On Mon, 02 Jun 2008 17:25:23 +0200 Adam Cécile wrote:
> >>>
> >>> I do not own a AMD Geode but..
> >>>
> >>>   
> >>>       
> >>>> Loaded kernel modules:
> >>>> gandalf@alix:~$ lsmod | grep -e cry -e oc
> >>>> cryptodev              13988  3
> >>>> crypto_null             2624  0
> >>>> cryptosoft             12136  0
> >>>> ocf                    28984  2 cryptodev,cryptosoft
> >>>>     
> >>>>         
> >>> .. you need to load the geode-aes module as well. You can find it in
> >>> your kernel configuration.
> >>>
> >>> Cryptographic API  ---> 
> >>>  [*]   Hardware crypto devices  --->
> >>>   <M>   Support for the Geode LX AES engine
> >>>
> >>> Try to load the modules in the following order:
> >>> geode-aes.ko
> >>> ocf.ko
> >>> cryptosoft.ko
> >>> cryptodev.ko 
> >>>
> >>> bye,
> >>> danm
> >>>
> >>>   
> >>>       
> >> gandalf@alix:~$ cat /etc/modules
> >> # /etc/modules: kernel modules to load at boot time.
> >> #
> >> # This file contains the names of kernel modules that should be loaded
> >> # at boot time, one per line. Lines beginning with "#" are ignored.
> >>
> >> # Geode WatchDog
> >> geodewdt
> >>
> >> # Geode LX AES hardware crypto
> >> geode-aes
> >> geode-rng
> >> ocf
> >> cryptosoft
> >> cryptodev
> >>
> >> # Alix LEDs driver
> >> leds-alix
> >>
> >> # Sensors
> >> lm90
> >>
> >> It's already loaded. Any other idea ? ;)
> >>     
> >
> > Did you check that with a "lsmod" to be sure ?
> >
> > Thanks,
> > Davidm
> >
> >   
> Hello,
> 
> I've updated to debian's kernel 2.6.25-3-686 + latest ocf patch and I
> still don't see any performance improvement.


Have a look for emails by "Andreas Steinel" just recently , he seems to
have got it working,  might be some clues.
More below.


> gandalf@wrap:~$ lsmod | grep -e cry -e oc
> cryptodev              13572  3
> crypto_null             3392  0
> cryptosoft             11624  0
> ocf                    29176  2 cryptodev,cryptosoft
> crypto_blkcipher       18564  4 crypto_null,ecb,cbc,geode_aes
> dock                   10320  1 libata

Make sure you load crypto_blkcipher before you load ocf.

> gandalf@wrap:~$ ls -lah /dev/crypto
> crw-rw-rw- 1 root root 10, 70 Jan  1  2000 /dev/crypto
> 
> gandalf@wrap:~$ openssl engine
> (cryptodev) BSD cryptodev engine
> (padlock) VIA PadLock (no-RNG, no-ACE)
> (dynamic) Dynamic engine loading support
> 
> gandalf@wrap:~$ openssl speed -evp aes128 -elapsed
> You have chosen to measure elapsed time instead of user CPU time.
> To get the most accurate results, try to run this
> program when this computer is idle.
> Doing aes-128-cbc for 3s on 16 size blocks: 123525 aes-128-cbc's in 3.00s
> Doing aes-128-cbc for 3s on 64 size blocks: 119105 aes-128-cbc's in 3.00s
> Doing aes-128-cbc for 3s on 256 size blocks: 103091 aes-128-cbc's in 3.00s
> Doing aes-128-cbc for 3s on 1024 size blocks: 68212 aes-128-cbc's in 3.00s
> Doing aes-128-cbc for 3s on 2048 size blocks: 46401 aes-128-cbc's in 3.00s
> OpenSSL 0.9.8g 19 Oct 2007
> built on: Mon Jun  2 14:52:51 UTC 2008
> options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long)
> aes(partial) blowfish(idx)
> compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT
> -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DL_ENDIAN -DTERMIO -O3
> -march=i586 -Wa,--noexecstack -g -Wall -DOPENSSL_BN_ASM_PART_WORDS
> -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
> available timing options: TIMES TIMEB HZ=100 [sysconf value]
> timing function used: ftime
> The 'numbers' are in 1000s of bytes per second processed.
> type             16 bytes     64 bytes    256 bytes   1024 bytes   2048
> bytes
> aes-128-cbc        658.80k     2540.91k     8797.10k    23283.03k   
> 31676.42k


Ok,  this looks like you are using OCF  for crypto,  it is easy to tell
because the small packets do not get the same total throughput as the
large packets.

If you "rmmod cryptodev" then run the test again it should confirm this.


> gandalf@wrap:~$ openssl speed -evp aes128 -elapsed -engine cryptodev
> engine "cryptodev" set.
> You have chosen to measure elapsed time instead of user CPU time.
> To get the most accurate results, try to run this
> program when this computer is idle.
> Doing aes-128-cbc for 3s on 16 size blocks: 123212 aes-128-cbc's in 3.00s
> Doing aes-128-cbc for 3s on 64 size blocks: 119413 aes-128-cbc's in 3.00s
> Doing aes-128-cbc for 3s on 256 size blocks: 103493 aes-128-cbc's in 3.00s
> Doing aes-128-cbc for 3s on 1024 size blocks: 67906 aes-128-cbc's in 3.00s
> Doing aes-128-cbc for 3s on 2048 size blocks: 46018 aes-128-cbc's in 3.00s
> OpenSSL 0.9.8g 19 Oct 2007
> built on: Mon Jun  2 14:52:51 UTC 2008
> options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long)
> aes(partial) blowfish(idx)
> compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT
> -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DL_ENDIAN -DTERMIO -O3
> -march=i586 -Wa,--noexecstack -g -Wall -DOPENSSL_BN_ASM_PART_WORDS
> -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
> available timing options: TIMES TIMEB HZ=100 [sysconf value]
> timing function used: ftime
> The 'numbers' are in 1000s of bytes per second processed.
> type             16 bytes     64 bytes    256 bytes   1024 bytes   2048
> bytes
> aes-128-cbc        657.13k     2546.63k     8831.40k    23178.58k   
> 31414.95k

These numbers at the same as above.  The reason for that is openssl will
use ocf by default if it is enabled.  The best way to check is to remove
the cryptodev driver and see what the performance is.

Either way,  you are getting 31414.95k bytes of AES throughput.  Thats
around 250Mbits/s using 2k packets.  Are you sure that is not fast enough ?

Check your numbers with cryptodev unloaded to know for sure.

> Only OpenSSL hasn't been rebuilt with latest OCF patch but I'll do asap.
> Any pointers would be greatly appreciated (maybe my bench commands are
> just wrong ?).

No need to do that,  the patch hasn't changed since the last release (at
least I don't recall any changes ;-)

Cheers,
Davidm

-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org   http://www.snapgear.com

Re: [Ocf-linux-users] ocf-linux-20080704

[David M. <Dav...@se...>]

Jivin Vrabete, Brad lays it down ...
> >
> >Message: 3
> >Date: Fri, 4 Jul 2008 15:49:52 +1000
> >From: David McCullough <Dav...@se...>
> >Subject: [Ocf-linux-users] ocf-linux-20080704 - Asynchronous Crypto
> >	support	for linux
> >To: ocf...@li...
> >Message-ID: <200...@se...>
> >Content-Type: text/plain; charset=us-ascii
> >
> >
> >Hi all,
> >
> >A new release of the ocf-linux package is up (20080704):
> >
> >    http://ocf-linux.sourceforge.net/
> >
> >This is primarily to sync up with openswan 2.6 and should be considered
> >somewhat alpha level code for now.   Also figured I should get a full
> >snapshot out there ;-)
> >
> >	* lockup bug fixed
> >	* other cleanups
> >	* openswan-2.6.15dr2 patch
> >	* linux-2.6.25 support
> >
> >See the Changelog for more.  Tested under 2.6.25 on Xscale so far, so
> >anything else may be fun ;-)
> 
> Hi,
> 
> I have a couple of questions:
> - can an OCF version be used with an earlier version of Openswan? E.g. 
> 20080704 with Openswan 2.4.11?

Yes,  use the openswan patches from the lastest 2007 release,  it only
just moved to the 2.6 series last week.

The new OCF code will work with the older opwenswan-ocf patches just
fine.

> - I don't seem to find the Changelog file. Is it in the cvs repository?
> That's hard to access by someone behind a firewall. Would someone be so
> kind and post 
> it here?

The only available changelog is on ocf-linux.sourceforge.net in the
downloads area.  They list the changes from release to release.


Cheers,
Davidm

-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org   http://www.snapgear.com

Re: [Ocf-linux-users] Regarding ocf for ipsec

[David M. <Dav...@se...>]

Jivin Manish RATHI lays it down ...
> Hi,
>  ipsec in vannila linux kernel uses linux kernel crypto not OCF framework?

yes.

> I am using OCF driver  for crypto acceleration to be used with openssl engine.
> 
> Currently ipsec uses linux kernel crypto framework. So I've to write 2 drivers 

You could use the openswan KLIPS stack in the kernel instead.

> 1) kernel crypto driver 
> 2) OCF driver
> 
> I'd like to use single driver that can be used with OpenSSL/OCF and Linux kernel crypto.
> 
> Is there any stable patch available for ipsec in latest linux kernel so that it uses OCF?

No.  The linux kernel is doing it's own async crypto but I am not sure
which kernel is is/will appear in and how stable it is.

> Why OCF is not used in linux kernel for ipsec?

One reason is licensing (OCF is BSD license).

> I've read that current
> ipsec doesn't uses Bottom half so async API framework such as OCF is not
> required.  Is it correct?

An async api is required,  but previously the stack counld not handle
it.  Work is being done in the space by the linux crypto guys.

> What are the pros and cons of using OCF with ipsec? 

It goes faster,  you have to patch your kernel,

Cheers,
Davidm

-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org   http://www.snapgear.com