Date: Wed, 17 Nov 2010 00:19:26 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Mike Tancsa <mike@sentex.net> Cc: stable@freebsd.org Subject: Re: Call for testers: FPU changes Message-ID: <20101116221926.GN2392@deviant.kiev.zoral.com.ua> In-Reply-To: <4CE300DE.8010304@sentex.net> References: <20101115211350.GE2392@deviant.kiev.zoral.com.ua> <4CE1FDBA.9030403@sentex.net> <20101116094330.GH2392@deviant.kiev.zoral.com.ua> <4CE300DE.8010304@sentex.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--cUXk36noUJGm9fSL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 16, 2010 at 05:08:30PM -0500, Mike Tancsa wrote: > On 11/16/2010 4:43 AM, Kostik Belousov wrote: > > On Mon, Nov 15, 2010 at 10:42:50PM -0500, Mike Tancsa wrote: > >> On 11/15/2010 4:13 PM, Kostik Belousov wrote: > >>> > >>> Patch is at > >>> http://people.freebsd.org/~kib/misc/releng_8_fpu.1.patch > >> > >> > >> Hi, > >> One small failure on the patch > >> > >> The text leading up to this was: > >> -------------------------- > >> |Index: pc98/include/npx.h > >> |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> |--- pc98/include/npx.h (revision 215253) > >> |+++ pc98/include/npx.h (working copy) > >> -------------------------- > >> Patching file pc98/include/npx.h using Plan A... > >> Hunk #1 failed at 1. > >> 1 out of 1 hunks failed--saving rejects to pc98/include/npx.h.rej > > This is because our patch(1) in base is somewhat old, I believe. > > The diff was generated by svn diff from the up to date stable/8 > > checkout, and the reason for failure is expanded $FreeBSD$ tags. > >=20 > > Newer gnu patch, available in ports, handless this correctly, > > reporting about patches applied with "fuzz". > >=20 > >> > >> > >> I tested with openssl and openvpn and all seems to work great on the v= ia > >> board and my i5 board!! Simple test details at > >> > >> http://www.tancsa.com/fpu.html > >> > >> I will try out geli and some more extensive tests tomorrow > >> > >> Thanks for porting this back to RELENG_8 ! > > This is actually somewhat puzzling. Does openssl in base automatically > > use crypto(4) ? >=20 >=20 > I force it it via ssl.cnf >=20 >=20 > 0(achinetboot)% tail -11 /etc/ssl/openssl.cnf >=20 > openssl_conf =3D openssl_def >=20 > [openssl_def] > engines =3D openssl_engines >=20 > [openssl_engines] > padlock =3D cryptodev_engine >=20 > [cryptodev_engine] > default_algorithms =3D ALL > 0(achinetboot)% Ah, that explains the results. >=20 >=20 > The limiting factor here for ssh seems to be the 100Mb link my i5 box is > on. Here is with and without aesni loaded >=20 > 0(achinetboot)% /usr/bin/time scp -c aes128-cbc test.bin > mdtancsa@10.255.255.1:/dev/null > test.bin > 100% 88MB 11.0MB/s 00:08 > 8.14 real 0.44 user 0.57 sys > 0(achinetboot)% /usr/bin/time scp -c aes128-cbc test.bin > mdtancsa@10.255.255.1:/dev/null > test.bin > 100% 88MB 11.0MB/s 00:08 > 8.15 real 1.46 user 0.36 sys > 0(achinetboot)% >=20 > I will move it to gigabit to get a better test shortly. >=20 > >=20 > > Also, could you, please redo the speed tests for aesni(4) with the > > following patch applied over the driver sources ? > >=20 > > Thank you ! > >=20 > > diff --git a/sys/crypto/aesni/aesni_wrap.c b/sys/crypto/aesni/aesni_wra= p.c > > index 36c66ea..3fd397c 100644 > > --- a/sys/crypto/aesni/aesni_wrap.c > > +++ b/sys/crypto/aesni/aesni_wrap.c > > @@ -246,14 +246,21 @@ int >=20 >=20 >=20 > patch -p2 < a > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |diff --git a/sys/crypto/aesni/aesni_wrap.c b/sys/crypto/aesni/aesni_wrap= .c > |index 36c66ea..3fd397c 100644 > |--- a/sys/crypto/aesni/aesni_wrap.c > |+++ b/sys/crypto/aesni/aesni_wrap.c > -------------------------- > Patching file crypto/aesni/aesni_wrap.c using Plan A... > Hunk #1 succeeded at 246. > Hunk #2 succeeded at 271. > Hunk #3 succeeded at 324. > Hmm... Ignoring the trailing garbage. > done >=20 >=20 > Seems to work ok >=20 >=20 >=20 > 0(achinetboot)# kldload aesni > 0(achinetboot)# openssl speed -evp aes-128-cbc > 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: 2587085 aes-128-cbc's in 0.39s > Doing aes-128-cbc for 3s on 64 size blocks: 2425301 aes-128-cbc's in 0.38s > Doing aes-128-cbc for 3s on 256 size blocks: 1925353 aes-128-cbc's in 0.1= 9s > Doing aes-128-cbc for 3s on 1024 size blocks: 1098255 aes-128-cbc's in 0.= 11s > Doing aes-128-cbc for 3s on 8192 size blocks: 152631 aes-128-cbc's in 0.0= 5s > OpenSSL 0.9.8n 24 Mar 2010 > built on: date not available > options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) > aes(partial) blowfish(idx) > compiler: cc > available timing options: USE_TOD HZ=3D128 [sysconf value] > timing function used: getrusage > The 'numbers' are in 1000s of bytes per second processed. > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 > bytes > aes-128-cbc 105979.48k 404781.84k 2632455.13k 9955323.90k > 27619906.16k > 0(achinetboot)# >=20 > But there is a LOT of variation between runs for some reason. >=20 > I added to http://www.tancsa.com/fpu.html >=20 > the different runs >=20 >=20 Mike, thank you again. Would your conclusion be that the patch seems to increase the throughput of the aesni(4) ? I think that on small-sized blocks, when using aesni(4), the dominating factor is the copying/copyout of the data to/from the kernel address space. Still would be interesting to compare the full output of "openssl speed" on aesni(4) with and without the patch I posted. --cUXk36noUJGm9fSL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzjA24ACgkQC3+MBN1Mb4i4egCeP9uMBfgENlpjwj6fiXvrOnO5 A7MAoJQnVrl7XZXzx7ud07ERNhn6CLlW =r9gD -----END PGP SIGNATURE----- --cUXk36noUJGm9fSL--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101116221926.GN2392>