Re: Status of encryption hardware support in FreeBSD
Marc wrote: On Tue, 3 Jul 2001 [EMAIL PROTECTED] wrote: In a message dated 07/03/2001 11:57:44 AM Eastern Daylight Time, [EMAIL PROTECTED] writes: Now try to imagine a whole PC on a smaller board than a PIII CPU cartridge. If you can't, get a copy of the Embedded Systems magazine and look at the pictures in it. Imagine a complete 80186 system with 512k RAM and 512K flash disk, two serial ports, 14 digital IO lines and an Ethernet in a 32 pin DIL package. They are planning to replace the 80186 module by a 80386 in a few weeks. If you can't belive it you might take a look at www.bcl.de. Now if it only had enough flash for a PicoBSD it might make a good pocket ISDN router... We can picture it, but such a system can't route a full 100mb/s ethernet, so its fairly useless as a network device/router as is proposed here. So try the MachZ processor then... Screw the MachZ, look at PowerPC 405GP, Intel XScale, or any other processor that was *designed* for embedded communications work. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
Terry Lambert wrote: I think you'll find that Wes Peters has worked on a number of them as well (one of his is now called Intel InBusiness servers). My Internet Station ran VxWorks because we didn't have enough CPU budget for anything else, and because we were fighting political wars over a lot of issues back then. Later members of the InBusiness line, produced to my great astonishment, did use FreeBSD, but not the one that needed it the most -- the email server. Most of us were extremely pissed off when /dev/random went in and made 386 and 486 class hardware crawl on its knees, since embedded systems have different requirements for things like moving parts, heat dissipation, etc., than general purpose computers posing as embedded systems. Trying to run any sort of SSL on a 486-class processor now is a losing game, wiping out two entire generations of processors. PCs are very expensive for such inexpensive computers. Now I'm working on a design that is powered by a 12-volt deep cycle battery and keep ending up with RTEMS or uClinux on the device because *BSD doesn't really do low-power (as in current draw) hardware anymore. I can base this project on an Atmel AT91 (ARM THUMB) or Motorola ColdFire cpu, load a pretty much standard uClinux or RTEMS build on it, and still be able to talk on the VHF, or I can run it on BSD and sell generators to go with it. Sigh -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
[EMAIL PROTECTED] wrote: Again, you are only considering your personal case. If crypto should be needed on an embedded appliance, I don't think they would need a lightning-fast processor and VGA support, when crypto is all they want. Your premise that embedded appliances are somehow doomed to use pitifully outdated processors is simply wrong. Embedded MBs with speeds enough to eliminate the requirement for 1) a slot and 2) an external board are available for less than the delta in cost. So, logically speaking, anyone with a requirement for crypto would simply chose a faster embedded MB solution. Listen, Im not trying to say that your project has no merit. My post was originally meant to illustrate to others, who may have been unduly excited about the prospects, that such a product does not buy you much in a normal environment. I think that now we have established that its merits are limted to low-speed embedded solutions, which is just was I was trying to say. ClickArray uses the BroadCom 4-crypto-engines-per-board, even though the main CPU speed is very, very high (GHz range). Using the card to offload handshakes speeds things up considerably, though it is still faster to do the actual SSL termination on the main CPU. The next generation of the board they've announced has 16 engines per board, instead of just 4. The messay part of SSL is the 1024 bit key generation, which is definitely _not_ best done on the main CPU. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
[EMAIL PROTECTED] wrote: Entire PIII MBs are available for under $60. Your concept that the delta in cost between a 486 chipset and PIII is more that that is utterly ridiculous PIII chipsets and 486 chipsets cost the same in quantity. Try using a resource other than your Radio Shack catalogue please. Actually, I can get a 486 macrocell and etherenet controllers, along with a big chunk of RAM, a North Bridge, etc., all put on a single die, and go to fab for under $30,000. I can do the same thing with a PPC603e core, using IBM's Blue Logic library. If I'm building an embedded system, I really don't need more horseposer than that, and being able to run without a fan, and fit into the form-factor of a modem or a set top box is generally much more important. You know that FreeBSD can be netboot onto the Apple AirPort base station, right? Footprint is the name of the game, when you are building embedded systems; when we did the InterJet and InterJet II at Whistle/IBM, we ran with self-designed motherboards. The InterJet had a built-in UPS. We funded the Soft Updates work, and had a custom power supply with a very long DC hold-up time following AC fail in order to get rid of the UPS. One of our main mistakes in the InterJet II, IMO, was going to a higher power CPU, which needed a fan on the CPU, and a fan in the case, as a result us the Cyrix Media GX processor, which was mostly there to do crypto. We would have been much better off with rolling the cost savings of continuing to use a 486 class CPU into the profitability of the product, and putting a dumb crypto chipset on the board to handle the load (IBM even makes a chipset perfect for this, and IBM had bought us by the time the InterJet II design got finalized). One other thing to realize is that every $1 in cost ends up turning into $2 to the customer, so installing another serial port connector when you don't need to is a very costly proposition. I'm now working on an appliance device (rackmount). It is based on a general purpose motherboard right now (as you suggest), but it still has crypto hardware to push up the connection rate for SSL connections. We will need to eventually go to a special purpose motherboard, so that we can have things like watchdog timers, etc., which are missing from general purpose computers. All told, I've now worked on 4 embedded systems that use FreeBSD. I think you'll find that Wes Peters has worked on a number of them as well (one of his is now called Intel InBusiness servers). Most of us were extremely pissed off when /dev/random went in and made 386 and 486 class hardware crawl on its knees, since embedded systems have different requirements for things like moving parts, heat dissipation, etc., than general purpose computers posing as embedded systems. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
Sergey Babkin wrote: [EMAIL PROTECTED] wrote: Entire PIII MBs are available for under $60. Your concept that the delta in cost between a 486 chipset and PIII is more that that is utterly ridiculous PIII chipsets and 486 chipsets cost the same in quantity. Try using a resource other than your Radio Shack catalogue please. Now try to imagine a whole PC on a smaller board than a PIII CPU cartridge. If you can't, get a copy of the Embedded Systems magazine and look at the pictures in it. Now try to imagine an entire computer system on an 8-pin chip. The world of embedded systems spans a huge range of capabilities, but PIII's are not common because they cost too much, take too many resources in terms of support chips, and produce WAY too much heat. It's pretty difficult to put a $180 CPU chip in a router that sells for $199 retail. This entire conversation has been incredibly stupid, based on one contender displaying his abject ignorance of what embedded systems are and everyone else trying to teach the pig to sing. Can we just stop this? -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
In article [EMAIL PROTECTED] [EMAIL PROTECTED] (Sergey Babkin) wrote: Now try to imagine a whole PC on a smaller board than a PIII CPU cartridge. If you can't, get a copy of the Embedded Systems magazine and look at the pictures in it. Imagine a complete 80186 system with 512k RAM and 512K flash disk, two serial ports, 14 digital IO lines and an Ethernet in a 32 pin DIL package. They are planning to replace the 80186 module by a 80386 in a few weeks. If you can't belive it you might take a look at www.bcl.de. Now if it only had enough flash for a PicoBSD it might make a good pocket ISDN router... Noses. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
In a message dated 07/03/2001 11:57:44 AM Eastern Daylight Time, [EMAIL PROTECTED] writes: Now try to imagine a whole PC on a smaller board than a PIII CPU cartridge. If you can't, get a copy of the Embedded Systems magazine and look at the pictures in it. Imagine a complete 80186 system with 512k RAM and 512K flash disk, two serial ports, 14 digital IO lines and an Ethernet in a 32 pin DIL package. They are planning to replace the 80186 module by a 80386 in a few weeks. If you can't belive it you might take a look at www.bcl.de. Now if it only had enough flash for a PicoBSD it might make a good pocket ISDN router... We can picture it, but such a system can't route a full 100mb/s ethernet, so its fairly useless as a network device/router as is proposed here. B To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
On Tue, 3 Jul 2001 [EMAIL PROTECTED] wrote: In a message dated 07/03/2001 11:57:44 AM Eastern Daylight Time, [EMAIL PROTECTED] writes: Now try to imagine a whole PC on a smaller board than a PIII CPU cartridge. If you can't, get a copy of the Embedded Systems magazine and look at the pictures in it. Imagine a complete 80186 system with 512k RAM and 512K flash disk, two serial ports, 14 digital IO lines and an Ethernet in a 32 pin DIL package. They are planning to replace the 80186 module by a 80386 in a few weeks. If you can't belive it you might take a look at www.bcl.de. Now if it only had enough flash for a PicoBSD it might make a good pocket ISDN router... We can picture it, but such a system can't route a full 100mb/s ethernet, so its fairly useless as a network device/router as is proposed here. So try the MachZ processor then... -marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
In article [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: We can picture it, but such a system can't route a full 100mb/s ethernet, so its fairly useless as a network device/router as is proposed here. You're a real guru. Right. ISDN gives you about raw 192 kBit/s (144 kBit/s on the S0 bus) to work on. Of course this can't be sent across a 10 MBit/s link. How could I forget that. The device might also get used in a battery powered secure mobile device for EFT applications so even AOL users who don't have anything but fairly useless credit cards won't starve if they have to shop for their groceries at a street market. The developers would probably have preferred an ARM based solution to start with (to quote Apple's Newton team: it offered more mips per Wh) but its power balance is quite ok and the device is able to sort out itself whether it has to upload its accumulated transactions via serial or ethernet. Securely. No go and pray your buy a bigger CPU and a hotter power supply mantra somewhere else, it's getting tiring. Hand grenades aren't always the solution if all you try to is chasing a rabbit. Noses. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
In a message dated 07/03/2001 12:58:04 PM Eastern Daylight Time, [EMAIL PROTECTED] writes: Imagine a complete 80186 system with 512k RAM and 512K flash disk, two serial ports, 14 digital IO lines and an Ethernet in a 32 pin DIL package. They are planning to replace the 80186 module by a 80386 in a few weeks. If you can't belive it you might take a look at www.bcl.de. Now if it only had enough flash for a PicoBSD it might make a good pocket ISDN router.. . We can picture it, but such a system can't route a full 100mb/s ethernet, so its fairly useless as a network device/router as is proposed here. And where, pray tell, am I going to find a 100/mbit ISDN link? I'd sure like one, the 144k IDSL stuff is really slow. We were talking about the merits of using external encryption hardware on a 486 based platform VS a faster platform. You, it seems, are talking about the merits of slow embedded hardware, which has nothing to do with the discussion at hand. B To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
I think you've missed the fact that the '486 solution requires an add-on board (priced at $80.) and the faster cpu solution doesnt. That adds a lot of margin to get a faster MB, more than enough to compensate for the board. Not necessarily. The upgraded motherboard also requires a faster processor, and the two parts added together are almost certainly going to be more than $80. There is nothing more annoying than someone who argues subjects he clearly knows nothing about. I agree. :) You are way off on your pricing. Way off. A 633 Celeron is under 50. Q1 for petes sake. The cost difference would be less than $20. in quantity. It would be less than $80. Q1. That's just CPU. You've left off the motherboard, as well as the memory and other supporting hardware required for the CPU to do the work. Theres an old saying about being penny-wise and pound foolish. Using a 486 in todays networking and cost environment is just plain moronic. See your first sentence. You *really* don't know what you are talking about. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
In a message dated 07/02/2001 12:16:47 PM Eastern Daylight Time, [EMAIL PROTECTED] writes: You are way off on your pricing. Way off. A 633 Celeron is under 50. Q1 for petes sake. The cost difference would be less than $20. in quantity. It would be less than $80. Q1. That's just CPU. You've left off the motherboard, as well as the memory and other supporting hardware required for the CPU to do the work. Entire PIII MBs are available for under $60. Your concept that the delta in cost between a 486 chipset and PIII is more that that is utterly ridiculous PIII chipsets and 486 chipsets cost the same in quantity. Try using a resource other than your Radio Shack catalogue please. B To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
On Mon, Jul 02, 2001 at 06:08:31PM -0400, [EMAIL PROTECTED] wrote: In a message dated 07/02/2001 12:16:47 PM Eastern Daylight Time, [EMAIL PROTECTED] writes: You are way off on your pricing. Way off. A 633 Celeron is under 50. Q1 for petes sake. The cost difference would be less than $20. in quantity. It would be less than $80. Q1. That's just CPU. You've left off the motherboard, as well as the memory and other supporting hardware required for the CPU to do the work. Entire PIII MBs are available for under $60. Your concept that the delta in cost between a 486 chipset and PIII is more that that is utterly ridiculous PIII chipsets and 486 chipsets cost the same in quantity. Try using a resource other than your Radio Shack catalogue please. Might be true, but embedded folks tend to use something else than a run-of-the-mill mainboard. I think this whole thread boils down to: YMMV. Let it die (please..) -- | / o / / _ Arnhem, The Netherlandsemail: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
[EMAIL PROTECTED] wrote: Entire PIII MBs are available for under $60. Your concept that the delta in cost between a 486 chipset and PIII is more that that is utterly ridiculous PIII chipsets and 486 chipsets cost the same in quantity. Try using a resource other than your Radio Shack catalogue please. Now try to imagine a whole PC on a smaller board than a PIII CPU cartridge. If you can't, get a copy of the Embedded Systems magazine and look at the pictures in it. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
In a message dated 06/29/2001 11:01:16 AM Eastern Daylight Time, [EMAIL PROTECTED] writes: Really? Have you even looked at the net4501 board which was mentioned? It's a single-board computer constructed for some specific communication applications, with no VGA or keyboard support, or spinning fans, and is pretty inexpensive and in a very small form factor. Why do I want to replace this with a new motherboard? Because my motherboard is 20 times faster, has VGA support,doesnt require an add-on board to do fast encryption and costs about the same as yours. Thats why. Again, you are only considering your personal case. If crypto should be needed on an embedded appliance, I don't think they would need a lightning-fast processor and VGA support, when crypto is all they want. Your premise that embedded appliances are somehow doomed to use pitifully outdated processors is simply wrong. Embedded MBs with speeds enough to eliminate the requirement for 1) a slot and 2) an external board are available for less than the delta in cost. So, logically speaking, anyone with a requirement for crypto would simply chose a faster embedded MB solution. Listen, Im not trying to say that your project has no merit. My post was originally meant to illustrate to others, who may have been unduly excited about the prospects, that such a product does not buy you much in a normal environment. I think that now we have established that its merits are limted to low-speed embedded solutions, which is just was I was trying to say. Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
Really? Have you even looked at the net4501 board which was mentioned? It's a single-board computer constructed for some specific communication applications, with no VGA or keyboard support, or spinning fans, and is pretty inexpensive and in a very small form factor. Why do I want to replace this with a new motherboard? Because my motherboard is 20 times faster, has VGA support,doesnt require an add-on board to do fast encryption and costs about the same as yours. Thats why. Again, you are only considering your personal case. If crypto should be needed on an embedded appliance, I don't think they would need a lightning-fast processor and VGA support, when crypto is all they want. Your premise that embedded appliances are somehow doomed to use pitifully outdated processors is simply wrong. Who said anything about pitifully outdated processors. I can buy a heck of alot of CPU horsepower w/out buying the latest/greatest CPU. As a matter of fact, in almost all cases, the best bang for the buck would be for processorts that you imply to 'pitfully outdated'. Embedded MBs with speeds enough to eliminate the requirement for 1) a slot and 2) an external board are available for less than the delta in cost. That's simply not true. If you are building 'truly embedded' systems (ie; 100K+ boxes), you're not going to be using 'off the shelf' PC parts. You're going to be specifying particular parts to be used, and in general the difference in cost of $1-5 for the CPU makes a *huge* difference in the price-point you are trying to make. Often times it's easier to build a hierarchy of products, with each individual tier having the same 'basic' setup (keeping costs low), and by adding additional 'special purpose' boards, you can increase the functionality of the box by only increasing the costs trivially. So, logically speaking, anyone with a requirement for crypto would simply chose a faster embedded MB solution. You seem to have a different definition of embedded than many others do Bryan. Have you ever been involved with specifying and building embedded systems products, or are you just talking out of the side of your mouth? Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
In a message dated 06/30/2001 3:44:04 PM Eastern Daylight Time, [EMAIL PROTECTED] writes: Your premise that embedded appliances are somehow doomed to use pitifully outdated processors is simply wrong. Who said anything about pitifully outdated processors. I can buy a heck of alot of CPU horsepower w/out buying the latest/greatest CPU. As a matter of fact, in almost all cases, the best bang for the buck would be for processorts that you imply to 'pitfully outdated'. I think you've missed the fact that the '486 solution requires an add-on board (priced at $80.) and the faster cpu solution doesnt. That adds a lot of margin to get a faster MB, more than enough to compensate for the board. Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
Your premise that embedded appliances are somehow doomed to use pitifully outdated processors is simply wrong. Who said anything about pitifully outdated processors. I can buy a heck of alot of CPU horsepower w/out buying the latest/greatest CPU. As a matter of fact, in almost all cases, the best bang for the buck would be for processorts that you imply to 'pitfully outdated'. I think you've missed the fact that the '486 solution requires an add-on board (priced at $80.) and the faster cpu solution doesnt. That adds a lot of margin to get a faster MB, more than enough to compensate for the board. Not necessarily. The upgraded motherboard also requires a faster processor, and the two parts added together are almost certainly going to be more than $80. In any case, that's just one example. There are many more examples where a PIII-400 is more than adequate to do most of the processing, if you don't have to do encryption. If you involve encryption, we're talking alot more CPU, memory, and such. You can easily get an add-on board for *much* cheaper than to upgrade your memory, mboard, and CPU. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
Hi, Bryan, again you're missing the point :-) You're working out from just processing power, in the embedded world you usually start from somewhere else In the case of my products, the requirement are small size, low cost, no moving parts (no fans or disks), long life, low power, meaning a power budget of 10W incl everything The 133 Mhz 486 processor use 2W and the encryption processor is also 2W. You cannot get any x86 processor that can meet the performance of the encryption processor without needing a fan And when you add the cost of all the other parts you need beside your mainboard and 1Ghz processor, it's also more expensive than my solution. But anyway, we can probably agree to disagree, so maybe we should let this tread die Soren I think you've missed the fact that the '486 solution requires an add-on board (priced at $80.) and the faster cpu solution doesnt. That adds a lot of margin to get a faster MB, more than enough to compensate for the board. Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
On Fri, Jun 29, 2001 at 10:55:39AM -0400, [EMAIL PROTECTED] wrote: In a message dated 6/28/01 11:16:31 PM Eastern Daylight Time, [EMAIL PROTECTED] writes: Really? Have you even looked at the net4501 board which was mentioned? It's a single-board computer constructed for some specific communication applications, with no VGA or keyboard support, or spinning fans, and is pretty inexpensive and in a very small form factor. Why do I want to replace this with a new motherboard? Because my motherboard is 20 times faster, has VGA support,doesnt require an add-on board to do fast encryption and costs about the same as yours. Thats why. Again, you are only considering your personal case. If crypto should be needed on an embedded appliance, I don't think they would need a lightning-fast processor and VGA support, when crypto is all they want. G'luck, Peter -- yields falsehood, when appended to its quotation. yields falsehood, when appended to its quotation. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
In a message dated 06/27/2001 11:06:12 PM Eastern Daylight Time, [EMAIL PROTECTED] writes: That's not really the point here, I was talking about lowest end hardware compared to high end CPU. If we compare with high end hardware, then we're talking about factor 50 faster than software There are chips out that can do 1Gbit 3-DES, given a 64bit/66Mhz PCI bus. I'm just starting with a low end chip to complement my 133 Mhz 486 based net4501 board, with the goal of low cost and low power, not absolute performance. Its cheaper and more flexible to buy a faster motherboard, which is the point to the rest of us who are deciding if we care about a hardware solution. Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
In a message dated 06/27/2001 11:06:12 PM Eastern Daylight Time, [EMAIL PROTECTED] writes: That's not really the point here, I was talking about lowest end hardware compared to high end CPU. If we compare with high end hardware, then we're talking about factor 50 faster than software There are chips out that can do 1Gbit 3-DES, given a 64bit/66Mhz PCI bus. I'm just starting with a low end chip to complement my 133 Mhz 486 based net4501 board, with the goal of low cost and low power, not absolute performance. Its cheaper and more flexible to buy a faster motherboard, which is the point to the rest of us who are deciding if we care about a hardware solution. Really? Have you even looked at the net4501 board which was mentioned? It's a single-board computer constructed for some specific communication applications, with no VGA or keyboard support, or spinning fans, and is pretty inexpensive and in a very small form factor. Why do I want to replace this with a new motherboard? Please consider that you probably can't imagine all the applications that these platforms might be used in, an the availability of fire-breathing Really Fast CPUs might not actually be applicable to some applications with very specific requirements. A new motherboard isn't going to be more flexible since it's likely to require a power supply larger than the whole low-power computer you propose to replace. I'd rather spend the $100 or $150 to add crypto performance for some applications and maintain the small form factor, low power consumption, and no moving parts. The rest of us covers quite a few people, with a variety of interesting applications. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
Hi, Btw, did I say that I'm planning to sell the 7951 based crypto board for around $80 in single unnit volume, both for the PCI and MiniPCI version And Mike, if my answer is just a sentence, I like to keep it on top, so people don't have to scroll all the way down to see what I'm writing Soren Louis A. Mamakos wrote: In a message dated 06/27/2001 11:06:12 PM Eastern Daylight Time, [EMAIL PROTECTED] writes: That's not really the point here, I was talking about lowest end hardware compared to high end CPU. If we compare with high end hardware, then we're talking about factor 50 faster than software There are chips out that can do 1Gbit 3-DES, given a 64bit/66Mhz PCI bus. I'm just starting with a low end chip to complement my 133 Mhz 486 based net4501 board, with the goal of low cost and low power, not absolute performance. Its cheaper and more flexible to buy a faster motherboard, which is the point to the rest of us who are deciding if we care about a hardware solution. Really? Have you even looked at the net4501 board which was mentioned? It's a single-board computer constructed for some specific communication applications, with no VGA or keyboard support, or spinning fans, and is pretty inexpensive and in a very small form factor. Why do I want to replace this with a new motherboard? Please consider that you probably can't imagine all the applications that these platforms might be used in, an the availability of fire-breathing Really Fast CPUs might not actually be applicable to some applications with very specific requirements. A new motherboard isn't going to be more flexible since it's likely to require a power supply larger than the whole low-power computer you propose to replace. I'd rather spend the $100 or $150 to add crypto performance for some applications and maintain the small form factor, low power consumption, and no moving parts. The rest of us covers quite a few people, with a variety of interesting applications. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
[EMAIL PROTECTED] wrote: In a message dated 06/24/2001 2:53:32 PM Eastern Daylight Time, [EMAIL PROTECTED] writes: And btw, hardware beats software anytime. The fastest PC processor right now is about the same speed as the slowest hardware. what are the numbers? Are you accounting for the overhead in accessing the hardware? the impact of the stop-and-wait requirements for hardware processing? What about bus availability in a heavily utilized router? You are going to double the bus requirement. I'm not claiming any specific numbers, just that the chip I'm using, the lowest end hi/fn 7951, is said to be faster than your typical highend 1Ghz CPU doing 3-DES. Most people take a rather trivial approach to such evaluations, and i suppose im concerned about anyone who thinks that hardware is always faster than software, because that argument is blatently wrong. a 33Mhz ASIC will not always be faster than the host, particularly with transfer and setup requirements. It has to be 3-5 times faster than the host just to break even. I'm only talking about this specific case of doing computing intensive encryption As a hardware designer, I'm very well aware of all the different bottlenecks. Regards, Soren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
Soren Kristensen [EMAIL PROTECTED] types: I'm not claiming any specific numbers, just that the chip I'm using, the lowest end hi/fn 7951, is said to be faster than your typical highend 1Ghz CPU doing 3-DES. [ ... ] I'm only talking about this specific case of doing computing intensive encryption As a hardware designer, I'm very well aware of all the different bottlenecks. The crucial bottleneck for this kind of thing is the doubling time. Unless your special purpose hardware doubles in speed as fast or faster than general purpose CPUs, then eventually it's going to be slow, then expensive, and finally dead. Given the two doubling times and current relative speed, you can easily predict when general purpose CPUs well be faster and then when they will be more cost effective. At that point, your special purpose hardware is dead, and just waiting for the rest of the world to realize it. Given the predicted lifetime, you can make a rational decision about whether it's worth the effort to support the hardware. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
Hi, That's not really the point here, I was talking about lowest end hardware compared to high end CPU. If we compare with high end hardware, then we're talking about factor 50 faster than software There are chips out that can do 1Gbit 3-DES, given a 64bit/66Mhz PCI bus. I'm just starting with a low end chip to complement my 133 Mhz 486 based net4501 board, with the goal of low cost and low power, not absolute performance. Soren Mike Meyer wrote: Soren Kristensen [EMAIL PROTECTED] types: I'm not claiming any specific numbers, just that the chip I'm using, the lowest end hi/fn 7951, is said to be faster than your typical highend 1Ghz CPU doing 3-DES. [ ... ] I'm only talking about this specific case of doing computing intensive encryption As a hardware designer, I'm very well aware of all the different bottlenecks. The crucial bottleneck for this kind of thing is the doubling time. Unless your special purpose hardware doubles in speed as fast or faster than general purpose CPUs, then eventually it's going to be slow, then expensive, and finally dead. Given the two doubling times and current relative speed, you can easily predict when general purpose CPUs well be faster and then when they will be more cost effective. At that point, your special purpose hardware is dead, and just waiting for the rest of the world to realize it. Given the predicted lifetime, you can make a rational decision about whether it's worth the effort to support the hardware. mike -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
On Wed, Jun 27, 2001 at 09:51:47PM -0500, Mike Meyer wrote: The crucial bottleneck for this kind of thing is the doubling time. Unless your special purpose hardware doubles in speed as fast or faster than general purpose CPUs, then eventually it's going to be slow, then expensive, and finally dead. Given the two doubling times and current relative speed, you can easily predict when general purpose CPUs well be faster and then when they will be more cost effective. At that point, your special purpose hardware is dead, and just waiting for the rest of the world to realize it. Given the predicted lifetime, you can make a rational decision about whether it's worth the effort to support the hardware. Can't you also make the assumption that hardware vendors will be upgrading their product with equal vigor? Supporting hardware now (when its faster than CPU) will make it much easier to support it later (when its still faster than CPU). -Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
Steve Ames [EMAIL PROTECTED] types: On Wed, Jun 27, 2001 at 09:51:47PM -0500, Mike Meyer wrote: The crucial bottleneck for this kind of thing is the doubling time. Unless your special purpose hardware doubles in speed as fast or faster than general purpose CPUs, then eventually it's going to be slow, then expensive, and finally dead. Given the two doubling times and current relative speed, you can easily predict when general purpose CPUs well be faster and then when they will be more cost effective. At that point, your special purpose hardware is dead, and just waiting for the rest of the world to realize it. Given the predicted lifetime, you can make a rational decision about whether it's worth the effort to support the hardware. Can't you also make the assumption that hardware vendors will be upgrading their product with equal vigor? Supporting hardware now (when its faster than CPU) will make it much easier to support it later (when its still faster than CPU). Actually, I *did* assume that. The question isn't about vigor, it's about results. That's why you need to know how fast the hardware vendors can double the speed of their product, so you can predict the points where software overtakes it and then becomes more cost effective - or demonstrate that that isn't going to happen. Past experience - LISP and Forth Machines, the Amiga graphics hardware, etc. - indicate that special purpose hardware doesn't get faster as fast as general purpose cpus. There's apparently more money to be made in making general purpose CPUs faster than in making special purpose hardware faster, so they throw more resources at it. Soren Kristensen [EMAIL PROTECTED] types: That's not really the point here, I was talking about lowest end hardware compared to high end CPU. If we compare with high end hardware, then we're talking about factor 50 faster than software There are chips out that can do 1Gbit 3-DES, given a 64bit/66Mhz PCI bus. I'm just starting with a low end chip to complement my 133 Mhz 486 based net4501 board, with the goal of low cost and low power, not absolute performance. Replies below the quote if you want to keep context. Low end, high end, and current relative speed are immaterial. If the doubling time for your special purpose hardware isn't as good as that for general purpose cpus, then it's a dead end. If you're planning a product around it - or are deciding whether or not to support it - then you need to take that into account. This doesn't mean the product is useless; it just means you need to plan on dealing with it being outpaced by general purpose CPUs at some point. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
In a message dated 06/24/2001 2:53:32 PM Eastern Daylight Time, [EMAIL PROTECTED] writes: And btw, hardware beats software anytime. The fastest PC processor right now is about the same speed as the slowest hardware. what are the numbers? Are you accounting for the overhead in accessing the hardware? the impact of the stop-and-wait requirements for hardware processing? What about bus availability in a heavily utilized router? You are going to double the bus requirement. Most people take a rather trivial approach to such evaluations, and i suppose im concerned about anyone who thinks that hardware is always faster than software, because that argument is blatently wrong. a 33Mhz ASIC will not always be faster than the host, particularly with transfer and setup requirements. It has to be 3-5 times faster than the host just to break even. Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
Soren Kristensen [EMAIL PROTECTED] writes: As I now has prototypes avaliable of low cost PCI and MiniPCI boards, moving to production in a couple of weeks, I would like to check up on the work, as I would really like to see FreeBSD support. The boards are now supported in OpenBSD 2.9. OK, so if I understand correctly, the encryption hardware in question offers a high-speed hardware implementation of the encryption algorithms used by IPSec, so it's a matter of a) having support code that interfaces with the hardware, possibly with a device interface to allow userland apps access to the encryption hardware and b) making our (well, KAME's) IPSec code use that instead of doing the encryption in software. Is that it, or did I misunderstand something? Now, if you want FreeBSD support for your hardware, all you have to do is find a willing developer whistles innocently, send him a sample board (or preferably two, for a full circuit, but one will do) with complete documentation and any additional resources you are willing and able to provide, and then wait a bit. Simply asking for someone to port the OpenBSD driver will not do - OpenBSD and FreeBSD are not very similar at the kernel level, and as others have stated before in a different context, driver source does not constitute adequate documentation. It helps, but it's neither sufficient nor necessary. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
Dag-Erling Smorgrav([EMAIL PROTECTED])@2001.06.24 17:48:47 +: Soren Kristensen [EMAIL PROTECTED] writes: As I now has prototypes avaliable of low cost PCI and MiniPCI boards, moving to production in a couple of weeks, I would like to check up on the work, as I would really like to see FreeBSD support. The boards are now supported in OpenBSD 2.9. OK, so if I understand correctly, the encryption hardware in question offers a high-speed hardware implementation of the encryption algorithms used by IPSec, so it's a matter of a) having support code that interfaces with the hardware, possibly with a device interface to allow userland apps access to the encryption hardware and b) making our (well, KAME's) IPSec code use that instead of doing the encryption in software. Is that it, or did I misunderstand something? i think ipsec crypto abstraction into hardware is one side of the medal, but the other side -- to be polished first -- ist getting openssl onto the iron. for my former employer i had my hands on rainbow crupto hardware. it is a pci card called cryptoswift with a number, indicating the amount of ssl handshakes per second. the company has been renamed to ivea (http://www.ivea.com/). i came across this board since it is used in several appliance style boxes such as the intel netsctructure ssl accelerators (drop-in https-http ethernet bridge). they had working support and drivers for 3.x, developed in-house and i started hacking up the code for 4.x, but then i left the company (had to leave the hardware there, of course). as far as i got, my experience with ssl handshake processing in hardware showed me a great improvement, since openssl plugs in the hardware to create random and to create session keys. stream crypto is spoken on the host, but this is done fast and very effieciently. if you offload the handshakes to the iron, most of you sysload goes away, of course. i did not find another vendor in europe that provides a similar chip on a pci card, doing the stuff on the iron on a very high level (the card speaks x.50x ascii armored certificates natively, as far as i could see. it would be interesting if somebody from the u.s. could join in and present a list of available hardware and corresponding vendor. if there is hardware available from a crypto-relaxed country, such as south africa or similar, this would also be _very_ interesting, IMHO. Now, if you want FreeBSD support for your hardware, all you have to do is find a willing developer whistles innocently, send him a sample board (or preferably two, for a full circuit, but one will do) with complete documentation and any additional resources you are willing and able to provide, and then wait a bit. Simply asking for someone to port the OpenBSD driver will not do - OpenBSD and FreeBSD are not very similar at the kernel level, and as others have stated before in a different context, driver source does not constitute adequate documentation. It helps, but it's neither sufficient nor necessary. as i said, there is a 3.x freebsd driver, would this help? i am not into writing drivers ;-) /k -- Sex is one of the nine reasons for reincarnation ... the other eight are unimportant. --Henry Miller KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/ karstenrohrbach.de -- alphangenn.net -- alphascene.org -- [EMAIL PROTECTED] GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46 Please do not remove my address from To: and Cc: fields in mailing lists. 10x PGP signature
Re: Status of encryption hardware support in FreeBSD
Karsten W. Rohrbach [EMAIL PROTECTED] writes: i think ipsec crypto abstraction into hardware is one side of the medal, but the other side -- to be polished first -- ist getting openssl onto the iron. What you're basically trying to say is that you want a userland interface to the crypto hardware, so that OpenSSL can take advatange of it if it's present? as i said, there is a 3.x freebsd driver, would this help? i am not into writing drivers ;-) Allow me to repeat myself: driver source does not constitute adequate documentation. It helps, but it's neither sufficient nor necessary. A 3.x driver *could* be ported forward to 4.x and 5.x, but the required changes are not trivial (newbus, SMPng...) and you'd still need sample boards for testing and debugging, and docs for reference when you don't understand what the existing driver is trying to do. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
Dag-Erling Smorgrav([EMAIL PROTECTED])@2001.06.24 18:20:53 +: Karsten W. Rohrbach [EMAIL PROTECTED] writes: i think ipsec crypto abstraction into hardware is one side of the medal, but the other side -- to be polished first -- ist getting openssl onto the iron. What you're basically trying to say is that you want a userland interface to the crypto hardware, so that OpenSSL can take advatange of it if it's present? yup, exactly. to me it seems to be a major problem to get some unified api out of openssl adressing fucnctions on the hardware -- i simply do not know how other crypto chipsets do it, i just investigated the rainbow board. they got a patch against openssl 0.9.5 i think, that glues in the driver calls instead of standard lib functions. as i said, there is a 3.x freebsd driver, would this help? i am not into writing drivers ;-) Allow me to repeat myself: driver source does not constitute adequate documentation. It helps, but it's neither sufficient nor necessary. yes yes yes ;-) you are perfectly right here. i just wanrted to mention that there is an _existant_ driver and patch against the openssl lib, also some test programs to look if the driver works, for freebsd 3.x. A 3.x driver *could* be ported forward to 4.x and 5.x, but the required changes are not trivial (newbus, SMPng...) and you'd still need sample boards for testing and debugging, and docs for reference when you don't understand what the existing driver is trying to do. sure. my impression with the rainbow guys was, that they are very open to the opensource community. they supplied a board, (user) docs and the unreleased driver/openssl code to us and i was very impressed about their attitude towards people hacking up their stuff *grin*. alas, i quit the company and i did not even start really hacking on the code to take it to a place even near to production. i see from their web page, that they now support freebsd 4.1-release, so it sounds rather appealing to me... /k -- Captain Hook died of jock itch. KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/ karstenrohrbach.de -- alphangenn.net -- alphascene.org -- [EMAIL PROTECTED] GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46 Please do not remove my address from To: and Cc: fields in mailing lists. 10x PGP signature
Re: Status of encryption hardware support in FreeBSD
Karsten W. Rohrbach [EMAIL PROTECTED] writes: yup, exactly. to me it seems to be a major problem to get some unified api out of openssl adressing fucnctions on the hardware -- i simply do not know how other crypto chipsets do it, i just investigated the rainbow board. they got a patch against openssl 0.9.5 i think, that glues in the driver calls instead of standard lib functions. Can you dig out this patch for me? It would be a big win if the userland interface to Soren's hardware were compatible with Rainbow's driver. yes yes yes ;-) you are perfectly right here. i just wanrted to mention that there is an _existant_ driver and patch against the openssl lib, also some test programs to look if the driver works, for freebsd 3.x. This would be useful for ensuring compatibility with Rainbow's stuff, especially if, as you say, they have a 4.1 version out now. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
In article local.mail.freebsd-hackers/[EMAIL PROTECTED] you write: sure. my impression with the rainbow guys was, that they are very open to the opensource community. they supplied a board, (user) docs and the unreleased driver/openssl code to us and i was very impressed about their attitude towards people hacking up their stuff *grin*. alas, i quit the company and i did not even start really hacking on the code to take it to a place even near to production. i see from their web page, that they now support freebsd 4.1-release, so it sounds rather appealing to me... Do you have a contact address? I am going to start implementing crypto offload in the next month and would like to be able to get support for as many devices as possible. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
In a message dated 6/24/01 12:33:25 PM Eastern Daylight Time, [EMAIL PROTECTED] writes: A 3.x driver *could* be ported forward to 4.x and 5.x, but the required changes are not trivial (newbus, SMPng...) and you'd still need sample boards for testing and debugging, and docs for reference when you don't understand what the existing driver is trying to do. I'd suggest doing a study on the benefits as well. With 1+Ghz processors, the advantages of doing this in hardware become less than in the old days. We did a study on compression hardware, and at 400Mhz is was faster to do it in software than with external hardware. The setup, write to hardware, read from hardware cycles were more than the software processing requirements. Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
Dag-Erling Smorgrav([EMAIL PROTECTED])@2001.06.24 18:38:31 +: Karsten W. Rohrbach [EMAIL PROTECTED] writes: yup, exactly. to me it seems to be a major problem to get some unified api out of openssl adressing fucnctions on the hardware -- i simply do not know how other crypto chipsets do it, i just investigated the rainbow board. they got a patch against openssl 0.9.5 i think, that glues in the driver calls instead of standard lib functions. Can you dig out this patch for me? It would be a big win if the userland interface to Soren's hardware were compatible with Rainbow's driver. i think it would be a wise choice to ask rainbow for the current stuff, as they are stating 4.1-rel would be supported. i get back with the contact addresses to you guys off-list. /k -- Life is a sexually transmitted disease. KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/ karstenrohrbach.de -- alphangenn.net -- alphascene.org -- [EMAIL PROTECTED] GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46 Please do not remove my address from To: and Cc: fields in mailing lists. 10x PGP signature
Re: Status of encryption hardware support in FreeBSD
Hi, Thanks for the responses so far. First, let me say that I'm a hardware guy, and don't know all the details of FreeBSD's network stack. There is two common kind of hardware encryption acceleration, and I think they're being mixed a little here. SSL is for secure web access, and the main need is for Public Key generating. This don't really have anything to do with the IP stack. Afaik, OpenSSL is more like a extension to the web server software. IPSec is for secure communication, and the main need is for symmetric data encryption, typically using 3-DES. This need to be closely integrated in the IP stack. The boards I'm doing now, is based on a Hi/fn 7951, with is designed for VPM routers doing IPSec. It's supported in OpenBSD 2.9. And btw, hardware beats software anytime. The fastest PC processor right now is about the same speed as the slowest hardware The reason why I posted originally was the figure out who are working on these things, as I remember seing a post some time ago about work being done to import some of the IPSec work from OpenBSD. The Kame project people might be the ones to talk to, but isn't there a need for a FreeBSD specifec hardware driver anyway ? I will be happy to donate hardware to the FreeBSD project. Regards, Soren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
Bsdguru == Bsdguru [EMAIL PROTECTED] writes: Bsdguru I'd suggest doing a study on the benefits as well. With 1+Ghz Bsdguru processors, the advantages of doing this in hardware become Bsdguru less than in the old days. Think about the embedded market, where 486 class processors are still widely used (just like Soren's net4501) Eric Masson -- Je cherche une methode pour verifier si le port 515 est a l'ecoute. Cette requete est a envoyer d'une station Solaris vers un serveur NT. use Net::TCP; $object = new Net::TCP playstation, 515; $ok = $object-connect; -- SB in Guide du linuxien pervers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
On Sun, Jun 24, 2001 at 06:38:31PM +0200, Dag-Erling Smorgrav wrote: Karsten W. Rohrbach [EMAIL PROTECTED] writes: yup, exactly. to me it seems to be a major problem to get some unified api out of openssl adressing fucnctions on the hardware -- i simply do not know how other crypto chipsets do it, i just investigated the rainbow board. they got a patch against openssl 0.9.5 i think, that glues in the driver calls instead of standard lib functions. Can you dig out this patch for me? It would be a big win if the userland interface to Soren's hardware were compatible with Rainbow's driver. I believe there is support in OpenSSL for this now (though not in the version we currently have imported; it's the OpenSSL-engine branch which supports hardware offload). Once there's a point to do so (e.g. whatever relevant kernel support), I can import this into FreeBSD. Kris PGP signature
Re: Status of encryption hardware support in FreeBSD
In article local.mail.freebsd-hackers/[EMAIL PROTECTED] you write: Hi, Thanks for the responses so far. First, let me say that I'm a hardware guy, and don't know all the details of FreeBSD's network stack. There is two common kind of hardware encryption acceleration, and I think they're being mixed a little here. SSL is for secure web access, and the main need is for Public Key generating. This don't really have anything to do with the IP stack. Afaik, OpenSSL is more like a extension to the web server software. IPSec is for secure communication, and the main need is for symmetric data encryption, typically using 3-DES. This need to be closely integrated in the IP stack. The boards I'm doing now, is based on a Hi/fn 7951, with is designed for VPM routers doing IPSec. It's supported in OpenBSD 2.9. And btw, hardware beats software anytime. The fastest PC processor right now is about the same speed as the slowest hardware The reason why I posted originally was the figure out who are working on these things, as I remember seing a post some time ago about work being done to import some of the IPSec work from OpenBSD. The Kame project people might be the ones to talk to, but isn't there a need for a FreeBSD specifec hardware driver anyway ? Yes; the hardware will need a specific driver for the board. Also, the interface into the IP stack needs to be defined as well, this depends on what capabilities the board can provide. ISTR that various boards have different requirements from the stack, and one item that I'm focusing on is to try to work out an approach that will work for various chips on the market. Hopefully, this can be done in much the same way as the TCP/UDP/IP hardware checksum offload code that I did earlier. As such, the more information I get about the the interfaces the hardware requires the better. Of course, in order to write a driver for FreeBSD, I'd need complete programming details as well. I will be happy to donate hardware to the FreeBSD project. I'll contact you offline about this. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
Soren Kristensen [EMAIL PROTECTED] writes: SSL is for secure web access, and the main need is for Public Key generating. This don't really have anything to do with the IP stack. Afaik, OpenSSL is more like a extension to the web server software. Try 'man openssl', or just 'openssl -help'. You'll be surprised... DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
On Fri, 22 Jun 2001 13:20:33 -0700
Soren Kristensen [EMAIL PROTECTED] said:
soren There has been some talks earlier about importing the OpenBSD code for
soren encryption hardware support.
soren As I now has prototypes avaliable of low cost PCI and MiniPCI boards,
soren moving to production in a couple of weeks, I would like to check up on
soren the work, as I would really like to see FreeBSD support. The boards are
soren now supported in OpenBSD 2.9.
soren Could the responsible person, or anybody who knows, please post or email
soren a status ?
Because, FreeBSD's IPsec support comes from KAME, please contact to
KAME guys. [EMAIL PROTECTED] is good place.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Status of encryption hardware support in FreeBSD
In article local.mail.freebsd-hackers/[EMAIL PROTECTED] you write: Hi, There has been some talks earlier about importing the OpenBSD code for encryption hardware support. As I now has prototypes avaliable of low cost PCI and MiniPCI boards, moving to production in a couple of weeks, I would like to check up on the work, as I would really like to see FreeBSD support. The boards are now supported in OpenBSD 2.9. I have some funding to add support for hardware crypto offload in the next few months, so this is on my plate ATM. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
