As we saw in Section 5.4, data copying and the PCI bus quickly become the limiting factor. In practice, the situation is even worse since cryptography is used in conjunction with either network security protocols, in which case the network interface card (NIC) contents for a slice of the PCI bandwidth, or with filesystem encryption, in which case the storage device claims a portion of the bus. This situation suggests that, for maximum performance, cryptographic support must be provided by the individual devices ( e.g., NICs, disk controllers, etc.). Alternatively, cryptographic support must be located elsewhere in the system architecture (e.g., attached to the main CPU, the system ``north bridge'' (as the video subsystem is), or the memory subsystem. Any of these approaches, if implemented correctly, will improve application performance by reducing contention for the PCI bus, but at the same time will create new challenges for operating systems that have to support these new devices, such as session migration and fail-over (which the OCF supports by design, as we discussed in Section 3).
Although the OCF does not directly take advantage of NICs that support IPsec-processing offloading, since they are not general-purpose cryptographic accelerators, we have extended the IPsec stack to use them. The cards of this type we are familiar with are 100 Mbps full-duplex Ethernet, and it seems reasonable to assume that they can achieve that performance, given our results with dedicated cryptographic processors. Unfortunately, at the time this paper was written, we did not have enough information to write a device driver that could take advantage of such features. We are also not aware of any commercially-available hard drive controllers that provide built-in encryption services.