[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTi=8BqWJj6CEdm5QxvTSB+JiJCkEBFU4LDmHGwfX@mail.gmail.com>
Date: Mon, 23 Aug 2010 11:34:54 +0200
From: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@...il.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Miloslav Trmač <mitr@...hat.com>,
Herbert Xu <herbert@...dor.hengli.com.au>,
linux-crypto@...r.kernel.org, Neil Horman <nhorman@...hat.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/19] RFC, v2: "New" /dev/crypto user-space interface
On Mon, Aug 23, 2010 at 10:09 AM, Arnd Bergmann <arnd@...db.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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists