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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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