Re: [Fwd: Interrupts question]
Alex Zbyslaw wrote: John Baldwin wrote: There's no easy answer on this. You'll have to run your own benchmarks. If you don't need USB, then you may just want to leave it out of your kernel which might help some. OK, thanks for the info and suggestions. Regrettably, leaving out USB isn't an option for us. From your dmesg excerpt it seems that you have at least three USB controllers in that machine. Depending on your requirements, it might make sense to disable all of them _except_ one, and then connect your USB devices to that one controller (using additional USB hubs if necessary). Of course, the controller that you keep enabled should be the one that's causing the least problems (which seems to be uhci1 USB-B in your case, if I read your first email correctly). 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. Can the denizens of this group enlighten me about what the advantages of Python are, versus Perl ? python is more likely to pass unharmed through your spelling checker than perl. -- An unknown poster and Fredrik Lundh ___ 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
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: [Fwd: Interrupts question]
Oliver Fromme wrote: Alex Zbyslaw wrote: John Baldwin wrote: There's no easy answer on this. You'll have to run your own benchmarks. If you don't need USB, then you may just want to leave it out of your kernel which might help some. OK, thanks for the info and suggestions. Regrettably, leaving out USB isn't an option for us. From your dmesg excerpt it seems that you have at least three USB controllers in that machine. Depending on your requirements, it might make sense to disable all of them _except_ one, and then connect your USB devices to that one controller (using additional USB hubs if necessary). Of course, the controller that you keep enabled should be the one that's causing the least problems (which seems to be uhci1 USB-B in your case, if I read your first email Thanks for the suggestion. Can you tell me how to disable specific controllers? Were you thinking BIOS? or FreeBSD? Can device.hints do this? uhci man page is somewhat brief. I'm not sure which of those controllers I might actually need and it might be none of them. The USB requirement is because there is a DRAC (remote console) card which simulates a USB keyboard/mouse and offhand I'm not sure what they are connected to. But if I know how to turn specific controllers off, I can just try and see if what I need still works :-) (Probably studying the dmesg will give me some hints). Thanks, --Alex ___ 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: swiN: clock sio process taking 75% CPU
Hi Gareth, Did you try to disable the console screensaver? Sometimes this helps. Message: 1 Date: Tue, 18 Jul 2006 13:17:32 +0100 From: Gareth McCaughan [EMAIL PROTECTED] Subject: swiN: clock sio process taking 75% CPU To: freebsd-hackers@freebsd.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii (I've asked this question on -questions and -stable, with no success; hence I'm taking it to the assembled wizardry of -hackers. A bit of googling suggests that I'm far from the first person to have had a similar problem, though it seems to be worse for me than for the others I've found.) I have a box running 6-STABLE, cvsupped last week. Until recently it was running 5.something and showed the same peculiar behaviour as I'm about to describe. Further back, it used to run 4.x, and I don't recall anything like this happening then. About 6 minutes after booting (on three occasions, but I don't guarantee this doesn't vary), a process (well, a kernel interrupt thread, I guess) that appears in the output of ps as [swi4: clock sio] begins to use about 3/4 of the machine's CPU. I think it does so more or less instantaneously. It continues to do so indefinitely, so far as I can tell. I'm not aware of anything specific that triggers this, though I suppose there must *be* something. It happens apparently spontaneously, on a lightly loaded machine. Those cycles are genuinely being consumed; other processes run much more slowly than they should, and take much more wall time than CPU time. I've tried diddling my kernel's HZ value; the behaviour with HZ=100 and with HZ=1000 is the same, so far as I'm able to tell. I've no idea whether it might be relevant, but I have option DEVICE_POLLING turned on; toggling sysctl kern.polling.enable doesn't seem to make any difference. The machine is a very uninteresting single-CPU Athlon box, clocked at 1.6GHz, several years old. Here's its dmesg output, with a few uninteresting bits of information leakage elided. -- victor cruceru Non est respondendum ad omnia. ( Cicero, Pro Murena Oratio ) ___ 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]
more if_tun frustration.
To recap, I have tun0: flags=8051UP,POINTOPOINT,RUNNING,MULTICAST mtu 1500 inet6 fe80::214:22ff:fede:f175%tun0 prefixlen 64 scopeid 0x5 inet 192.168.12.2 -- 192.168.22.1 netmask 0x Opened by PID 15236 And I see: [4:18:[EMAIL PROTECTED]:/usr/home/dgilbert netstat -rn Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire defaultxx.yy.zz.33UGS 1 3393155 bge0 xx.yy.zz.32/27 link#1 UC 00 bge0 xx.yy.zz.3300:80:c8:c9:22:31 UHLW2 115 bge0 1178 127.0.0.1 127.0.0.1 UH 0 6251818lo0 192.168.22.1 192.168.12.2 UH 00 tun0 frstratingly, when I ask: [4:21:[EMAIL PROTECTED]:/usr/home/dgilbert route get 192.168.22.1 route to: 192.168.22.1 destination: default mask: default gateway: strike1 interface: bge0 flags: UP,GATEWAY,DONE,STATIC And even more frustratingly, when I do: [4:16:[EMAIL PROTECTED]:/usr/home/dgilbert route add 192.168.24.1 192.168.12.2 add host 192.168.24.1: gateway 192.168.12.2 I then see: [4:18:[EMAIL PROTECTED]:/usr/home/dgilbert netstat -rn Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default66.96.20.33UGS 1 3393155 bge0 66.96.20.32/27 link#1 UC 00 bge0 66.96.20.3300:80:c8:c9:22:31 UHLW2 115 bge0 1178 127.0.0.1 127.0.0.1 UH 0 6251818lo0 192.168.22.1 192.168.12.2 UH 00 tun0 192.168.24.1 192.168.12.2 UGHS00 bge0 !?! Clearly, both 24.1 and 22.1 should route via tun0. Even though 22.1 says tun0 here, it in fact routes via bge0. Any clues offered as to what I'm doing wrong? Dave. -- |David Gilbert, Independent Contractor. | Two things can be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ 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: On the use of Tun interfaces.
Am 18.07.2006 um 06:39 schrieb David Gilbert: [3:15:[EMAIL PROTECTED]:~/devel/failsafe netstat -rn ... 192.168.22.1 192.168.12.2 UH 00 tun0 shouldn't the last route there be active? Any clues here? The last time I tried to get a tun interface set up (admittedly, back in 2.2 days), I had similiar problems with weird routing entries. IIRC, when configuring the tun interface, I failed to initialize all sockaddr's properly. The interface looked right, but the routes were botched. memset took care of it then. HTH, Stefan -- Stefan Bethke [EMAIL PROTECTED] Fon +49 170 346 0140 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: swiN: clock sio process taking 75% CPU
On Wednesday 19 July 2006 12:11, Gareth McCaughan wrote: (The particular screen saver I turned on was the one called warp; I haven't checked yet whether others have the same CPU-guzzling effect.) Actually, if you could test that, that would be helpful as that would narrow down where the bug is (syscons vs. the specific screen saver). -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: swiN: clock sio process taking 75% CPU
On Tuesday 2006-07-18 19:41, John Baldwin wrote: On Tuesday 18 July 2006 13:04, Gareth McCaughan wrote: On Tuesday 2006-07-18 16:54, Deomid Ryabkov wrote: Gareth McCaughan wrote: About 6 minutes after booting (on three occasions, but I don't guarantee this doesn't vary), a process (well, a kernel interrupt thread, I guess) that appears in the output of ps as [swi4: clock sio] begins to use about 3/4 of the machine's CPU. ... In that case, something is scheduling a lot of timeouts (via callout_reset() or timeout()) or you have timeout handlers that are taking a very long time to run. There aren't any easy ways to debug this. :-P You can try turning on the DIGANOSTIC check in kern_timeout.c to catch long-running timeouts, and you can try adding some KTR traces to softclock() to see which timeout functions are running and try to do some analysis on that. Thanks for the excellent advice! So, I turned on DIAGNOSTIC. That produced only two messages, both implicating what turns out to be the scrn_timer function from syscons.c. Once it took about 10ms, once about 100ms. There may for all I know have been an awful lot of 10ms-ish ones, since the threshold doubles on each report. (I'll check, but not today. If the answer is that the DIAGNOSTIC check just happened to catch a couple of freakishly long times, then we've found a situation where timeout functions can take too much CPU despite no single one being bad enough to be noticed; in that case, it might be worth enhancing the code in softclock() a bit.) After a quick glance at the code for scrn_timer, I tried disabling the console screen saver (saver=NO in rc.conf), and lo! all is now well. It seems to me that one of two things should be done. 1. If this is considered pilot error: Put a big warning somewhere saying that the screen saver makes no attempt to avoid eating all your CPU even when the machine is heavily loaded, and that it should therefore not be used if your machine will ever be used unattended. 2. If not: Find out why the syscons screen saver is taking so many cycles on my machine, and find a way to stop it. I'd be up for putting a bit of work into #2, but if the consensus is that I was a twit to think that I could use a machine for real work with the screen saver enabled then maybe #1 would do almost as well. (The particular screen saver I turned on was the one called warp; I haven't checked yet whether others have the same CPU-guzzling effect.) -- g ___ 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]
Re: kern/99979: Get Ready for Kernel Module in C++
Matthias Andree wrote: Deciding that some features are bad beforehand, before you evaluate them is IMO bad idea. Let interested people write a bunch of C++ modules with the complete language before deciding on what shouldn't be used. No, that won't work -- plus you need a bunch of run-time support (libstdc++ isn't exactly something that belongs into the kernel you know). libstdc++ would not be used, just as userland libc isn't. There is a spec for embedded C++, and it is certainly appropriate to kernel level development. Many parts of the language that require runtime support can be dropped with impunity; for example most embedded environments don't include for exceptions , rtti, many don't support objects at module scope with constructors/destructors, and so on. C++ itself is quite usable in an embedded environment, but you don't (and should not expect) to get the complete feature list of the mainstream language. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: [Fwd: Interrupts question]
On 17-Jul-2006 Alex Zbyslaw wrote: I was monitoring a machine with systat -vmstat and noticed something about the interrupts and I don't know if it's a problem or not. If it is a problem, is there anything I can do about it? The interrupts for the network interface (em0) on irq 64 exactly match those for a uhc device on irq 16. And the interrupts for the hardware raid (amr) on irq 46 exactly match those for a uhc device on irq 18. The problem involving the em device was solved in -current around January by making the device use a fast interrupt handler. If you can update to the latest driver from -current (if it will build on whatever version you are running), you can solve that part of the problem. I don't think there's an equivalent fix for the amr driver, though. John ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
