Siim Põder wrote: > Hi > > Karl O. Pinc wrote: >> On 04/28/2009 07:43:47 AM, Siim Põder wrote: >>> Karl O. Pinc wrote: >> I believe you, but you lost me when it comes to the explanation. What >> do ssh and grep have to do with adding a hardware encryption card? >> (I think maybe you're thinking I'm still talking about additional >> boxes. Recap: My point was that hardware encryption seems to involve >> kernel/userspace transitions too.) > > Yes, I was still talking about additional boxes. HW encryption (as i see > it) will not help at all, because by the current design, all packets > need to come to userland and go back to kernelland. Most likely to talk > to the HW encryption device, another round-trip to kernel space would be > needed?
It's very important to separate between HW encryption boxes (so called HSM's) and HW encryption accelerators. The HSM variant, which I have the impression you are talking about does encryption as well, but are also suitable for more high security encryption key management as well, with automatic key rotation, key access control, etc, etc. The HW encryption accelerator is very often a PCI card (might be they exists in ISA as well). These cards can basically only do encryption/decryption and that's it. An HSM is very often connected to a network, and uses the TCP/IP stack as the primary interface, thus giving a much more overhead in the packets being sent to the device. The advantage of an HSM is that it does safe and efficient encryption and decryption of bigger payloads. The HW accelerator will not have that extreme processing power as an HSM, but as they are working on the same internal bus as the rest of the hardware and closer to the encryption/decryption needing software, it can transfer smaller packages much more quickly and process smaller packages quicker than an HSM. I believe many of the accelerators also supports DMA, which practically gives it instant access to the user memory region where the payload is stored, without giving the CPU too much extra work. So for the HW accelerator in an OpenVPN setting, it will be kernel/user copy when a package is received on the input NIC and data is moved to user memory. The HW accelerator will process the user memory data and return it here, without involving the CPU too much. The CPU will move the processed data from user memory to the output NIC. With an HSM, the data will be needed to be copied from input NIC to user memory, the application will establish a connection to HSM, copy user memory to kernel space and push the data to the NIC where the HSM is located. Further a similar thing happens when the HSM has processed the data. So in this regard, I do not see any advantage of having an HSM processing VPN data, as the overhead will be the biggest disadvantage. But it will be suitable on bigger bulk jobs or jobs requiring strict key management. And for HW accelerator, it will be much more efficient, as it can work more independently in user memory (outside kernel space) and the driver will just signal the main process when data is ready. This is at least how I've understood things works ... I'm not claiming I'm right. It might be I've even misunderstood some bigger parts here as well :) kind regards, David Sommerseth >> Out of curiosity, did you test the scheduler per the link supplied by >> James MacLean? >> http://sourceforge.net/mailarchive/forum.php?thread_name=492DBF02.1070305%40ednet.ns.ca&forum_name=openvpn-devel > > We use openvpn in p2p setup so this would not be applicable. > > Siim > > ------------------------------------------------------------------------------ > Register Now & Save for Velocity, the Web Performance & Operations > Conference from O'Reilly Media. Velocity features a full day of > expert-led, hands-on workshops and two days of sessions from industry > leaders in dedicated Performance & Operations tracks. Use code vel09scf > and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf > _______________________________________________ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel
