On Mon, Aug 23, 2010 at 10:09 AM, Arnd Bergmann <a...@arndb.de> wrote:
>> This is an alternative design. There quite some reasons against that, >> such as the auditing features. For me the main reason was that there >> was no way to make it as fast (zero-copy) as this design, for the >> requirements we had (interface with existing crypto libraries through >> pkcs11). Zero-copy is important since crypto operations might involve >> large chunks of data. > You mean using a shared memory segment would not be possible without changing > the libpkcs11 interface? Indeed. The pkcs11 backend would have to copy the data to the shared segment, thus high-performance applications requiring zero-copy, would avoid to use this interface. Moreover if more than one applications are using the interface, the shared segment it is going to be a bottleneck. Having multiple shared segments might help, but I don't know how practical is something like that with the posix ipc. regards, Nikos -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
