Re: VIA padlock performance
Michael Reifenberger [EMAIL PROTECTED] wrote: with a via epia EN-15000 MB and an U160 scsi disk I get with eli(4) I get ~27-40MB/s read/write performance trough eli(4) with AES265 key. cryptotest gives: (totum)(root) ./cryptotest -a aes256 10 4096 7.838 sec, 20 aes256 crypts,4096 bytes, 104511751 byte/sec, 797.4 Mb/sec Quite cool. On my EPIA 1 (1GHz VIA Nehemia) I did some performance testing a few months ago under RELENG_6 (not sophisticated enough to call it benchmarking). For testing I used scp(1) of a large file (an ISO9660 image, 213 MBytes), because that's what I often need to do, so it's an important thing for me. These are the results (averages of several runs): A - No padlock(4) loaded: 213 MB in 56 seconds (3.8 MB/s) 37.5 s user (67%) 10.0 s sys (18%) 8.5 s int (15%) 0.0 s idle ( 0%) B - With padlock loaded, no bandwidth limit: 213 MB in 33 seconds (6.5 MB/s) 8.0 s user (24%) 16.0 s sys (48%) 9.0 s int (27%) 0.0 s idle ( 0%) C - With padlock loaded, bandwidth limited: 213 MB in 58 seconds (3.7 MB/s) 7.5 s user (13%) 14.5 s sys (25%) 7.0 s int (12%) 29.0 s idle (50%) As you can see, the throughput of scp was almost doubled when padlock(4) was enabled (from 3.8 MB/s to 6.5 MB/s). The time spent in user mode drops to about a fifth, while the sys time increases by 60%, which is to be expected (caused by the overhead of setting up and running the padlock engine). The interrupt time doesn't change at all. I did a third test where I limited the bandwith (Dummynet) to about the same value that was reached during the first test. Now the throughput was the same as in the first test (of course), but the CPU was 50% idle and available for other tasks. The other side of the test was a 1.6 GHz Pentium-M which had the test file in a large RAM disk, so the bottleneck was clearly the EPIA system. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. Perl is worse than Python because people wanted it worse. -- Larry Wall ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA padlock performance
Hello Oliver, On Wed, Jul 19, 2006 at 02:06:18PM +0200, Oliver Fromme wrote: On my EPIA 1 (1GHz VIA Nehemia) I did some performance testing a few months ago under RELENG_6 (not sophisticated enough to call it benchmarking). For testing I used scp(1) of a large file (an ISO9660 image, 213 MBytes), because that's what I often need to do, so it's an important thing for me. These are the results (averages of several runs): How exactly you enable it ? I have on -current: # kldload padlock DLOCK: No ACE support. module_register_init: MOD_LOAD (padlock, 0xc3dd790c, 0) error 22 However: % kldstat Id Refs AddressSize Name ... 201 0xc3dd6000 3000 padlock.ko 211 0xc3dd9000 19000crypto.ko 221 0xc3f2d000 9000 zlib.ko via5% uname -a FreeBSD via5 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Sun Jul 16 19:27:03 CEST 2006 [EMAIL PROTECTED]:/usr/obj/i386/usr/src/sys/DISKLESS i386 cheers, -a ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA padlock performance
Andrzej Tobola wrote: Oliver Fromme wrote: On my EPIA 1 (1GHz VIA Nehemia) I did some performance testing a few months ago under RELENG_6 (not sophisticated enough to call it benchmarking). For testing I used scp(1) of a large file (an ISO9660 image, 213 MBytes), because that's what I often need to do, so it's an important thing for me. These are the results (averages of several runs): How exactly you enable it ? You need crypto, cryptodev and padlock in your kernel; see the padlock(4) manpage (you can also load it as a module). That's all. You don't have to enable it explicitly. I have on -current: # kldload padlock DLOCK: No ACE support. That output is pretty clear: Either your CPU does not support ACE (that's the name of Nehemia's padlock engine), or it isn't recognized by your version of the padlock(4) driver. What kind of CPU do you have exactly? Please quote the line from your dmesg output. Mine says: CPU: VIA C3 Nehemiah+RNG+ACE (1002.28-MHz 686-class CPU) Origin = CentaurHauls Id = 0x698 Stepping = 8 Features=0x381b83fFPU,VME,DE,PSE,TSC,MSR,SEP,MTRR,PGE,CMOV,PAT,MMX,FXSR,SSE As you can see, it explicitly mentions ACE in the first line. By the way, it also mentions RNG which is a hardware random-number generator, which is supported and used by FreeBSD through /dev/random automatically. Cool, eh? :-) (You also get the information from ``sysctl hw.model''.) 201 0xc3dd6000 3000 padlock.ko 211 0xc3dd9000 19000crypto.ko You will also need cryptodev in addition to crypto. crypto manages only in-kernel access to the cryptographic facilities (including hardware acceleration through the padlock driver), which is used by FAST_IPSEC, for example. cryptodev will enable access by userland applications (e.g. scp) and libraries (OpenSSL) through /dev/crypto. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one? -- Tom Cargil, C++ Journal ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA padlock performance
On Wed, 19 Jul 2006, Oliver Fromme wrote: ... You will also need cryptodev in addition to crypto. crypto manages only in-kernel access to the cryptographic facilities (including hardware acceleration through the padlock driver), which is used by FAST_IPSEC, for example. cryptodev will enable access by userland applications (e.g. scp) and libraries (OpenSSL) through /dev/crypto. With OpenSSL you have two choices: engine cryptodev : uses /dev/crypto engine padlock : uses the xcrypt commands directly engine padlock should be the fastest of course. Bye/2 --- Michael Reifenberger, Business Development Manager SAP-Basis, Plaut Consulting Comp: [EMAIL PROTECTED] | Priv: [EMAIL PROTECTED] http://www.plaut.de | http://www.Reifenberger.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA padlock performance
On Tue, 18 Jul 2006, Christian Brueffer wrote: ... Nice, could you update padlock(4) with information about supported C7 processors? Something like the attached patch? Bye/2 --- Michael Reifenberger, Business Development Manager SAP-Basis, Plaut Consulting Comp: [EMAIL PROTECTED] | Priv: [EMAIL PROTECTED] http://www.plaut.de | http://www.Reifenberger.com Index: man4.i386/padlock.4 === RCS file: /home/ncvs/src/share/man/man4/man4.i386/padlock.4,v retrieving revision 1.3 diff -u -r1.3 padlock.4 --- man4.i386/padlock.4 5 Jun 2006 16:24:31 - 1.3 +++ man4.i386/padlock.4 19 Jul 2006 15:12:34 - @@ -29,7 +29,7 @@ .Os .Sh NAME .Nm padlock -.Nd driver for the cryptographic functions and RNG in VIA C3 and Eden processors +.Nd driver for the cryptographic functions in VIA C7, C3 and Eden processors .Sh SYNOPSIS To compile this driver into the kernel, place the following lines in your @@ -49,6 +49,9 @@ The C3 and Eden processor series from VIA include hardware acceleration for AES, as well as a hardware random number generator. .Pp +The C7 processor series from VIA include hardware acceleration for +AES, SHA and RSA, as well as a hardware random number generator. +.Pp The .Nm driver registers itself to accelerate AES operations for ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA padlock performance
On Wed, Jul 19, 2006 at 05:13:29PM +0200, Michael Reifenberger wrote: On Tue, 18 Jul 2006, Christian Brueffer wrote: ... Nice, could you update padlock(4) with information about supported C7 processors? Something like the attached patch? I'd prefer a more compact version. How about the attached patch? Also applies some more word smithing. - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D Index: padlock.4 === RCS file: /data/ncvs/freebsd/src/share/man/man4/man4.i386/padlock.4,v retrieving revision 1.3 diff -u -r1.3 padlock.4 --- padlock.4 5 Jun 2006 16:24:31 - 1.3 +++ padlock.4 19 Jul 2006 15:46:27 - @@ -24,12 +24,12 @@ .\ .\ $FreeBSD: src/share/man/man4/man4.i386/padlock.4,v 1.3 2006/06/05 16:24:31 pjd Exp $ .\ -.Dd June 5, 2006 +.Dd July 19, 2006 .Dt PADLOCK 4 i386 .Os .Sh NAME .Nm padlock -.Nd driver for the cryptographic functions and RNG in VIA C3 and Eden processors +.Nd driver for the cryptographic functions and RNG in VIA C3, C7 and Eden processors .Sh SYNOPSIS To compile this driver into the kernel, place the following lines in your @@ -47,14 +47,18 @@ .Ed .Sh DESCRIPTION The C3 and Eden processor series from VIA include hardware acceleration for -AES, as well as a hardware random number generator. +AES. +The C7 series includes hardware acceleration for AES, SHA and RSA. +All of the above processor series include a hardware random number generator. .Pp The .Nm driver registers itself to accelerate AES operations for .Xr crypto 4 . -It also registers itself to accelerate various HMAC algorithms, but there is no -hardware acceleration for those algorithms, this is only needed, so +It also registers itself to accelerate various HMAC algorithms, although +there is no +hardware acceleration for those algorithms. +This is only needed, so .Nm can work with .Xr fast_ipsec 4 . @@ -74,6 +78,7 @@ .Sh SEE ALSO .Xr crypt 3 , .Xr crypto 4 , +.Xr fast_ipsec 4 , .Xr intro 4 , .Xr random 4 , .Xr crypto 9 pgpi5dqQmbAKN.pgp Description: PGP signature
Re: VIA padlock performance
Michael Reifenberger wrote: On Wed, 19 Jul 2006, Oliver Fromme wrote: ... You will also need cryptodev in addition to crypto. crypto manages only in-kernel access to the cryptographic facilities (including hardware acceleration through the padlock driver), which is used by FAST_IPSEC, for example. cryptodev will enable access by userland applications (e.g. scp) and libraries (OpenSSL) through /dev/crypto. With OpenSSL you have two choices: engine cryptodev : uses /dev/crypto engine padlock : uses the xcrypt commands directly engine padlock should be the fastest of course. Is there any kind of locking (in hardware or software)? I mean, what happens if both padlock(4) and OpenSSL try to access the ACE engine directly? (If the answer is don't do that, then it's probably better to use cryptodev with OpenSSL, even if it's a little less efficient.) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs. -- Robert Firth ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA padlock performance
On Wed, 19 Jul 2006, Christian Brueffer wrote: ... Something like the attached patch? I'd prefer a more compact version. How about the attached patch? Also applies some more word smithing. commited. Thanks! Bye/2 --- Michael Reifenberger, Business Development Manager SAP-Basis, Plaut Consulting Comp: [EMAIL PROTECTED] | Priv: [EMAIL PROTECTED] http://www.plaut.de | http://www.Reifenberger.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA padlock performance
There's no locking in the hardware, all the xcrypt commands are ring3 accessible. Shouldn't be an issue to use either. Michael Reifenberger wrote: On Wed, 19 Jul 2006, Oliver Fromme wrote: ... You will also need cryptodev in addition to crypto. crypto manages only in-kernel access to the cryptographic facilities (including hardware acceleration through the padlock driver), which is used by FAST_IPSEC, for example. cryptodev will enable access by userland applications (e.g. scp) and libraries (OpenSSL) through /dev/crypto. With OpenSSL you have two choices: engine cryptodev : uses /dev/crypto engine padlock : uses the xcrypt commands directly engine padlock should be the fastest of course. Is there any kind of locking (in hardware or software)? I mean, what happens if both padlock(4) and OpenSSL try to access the ACE engine directly? (If the answer is don't do that, then it's probably better to use cryptodev with OpenSSL, even if it's a little less efficient.) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs. -- Robert Firth ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
VIA padlock performance
Hi, with a via epia EN-15000 MB and an U160 scsi disk I get with eli(4) I get ~27-40MB/s read/write performance trough eli(4) with AES265 key. cryptotest gives: (totum)(root) ./cryptotest -a aes256 10 4096 7.838 sec, 20 aes256 crypts,4096 bytes, 104511751 byte/sec, 797.4 Mb/sec not too bad, isn't it? :-) Bye/2 --- Michael Reifenberger, Business Development Manager SAP-Basis, Plaut Consulting Comp: [EMAIL PROTECTED] | Priv: [EMAIL PROTECTED] http://www.plaut.de | http://www.Reifenberger.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA padlock performance
On Tue, Jul 18, 2006 at 11:24:00AM +0200, Michael Reifenberger wrote: Hi, with a via epia EN-15000 MB and an U160 scsi disk I get with eli(4) I get ~27-40MB/s read/write performance trough eli(4) with AES265 key. cryptotest gives: (totum)(root) ./cryptotest -a aes256 10 4096 7.838 sec, 20 aes256 crypts,4096 bytes, 104511751 byte/sec, 797.4 Mb/sec not too bad, isn't it? :-) Nice, could you update padlock(4) with information about supported C7 processors? Thanks. - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp7NKsq7Heye.pgp Description: PGP signature
