Re: patch: multiple-request, async-request support for /dev/crypto

[email protected] (Christos Zoulas)
Newsgroups gmane.os.netbsd.devel.userlevel,gmane.os.netbsd.devel.crypto,gmane.os.netbsd.devel.kernel
Message-ID <[email protected]>
In article <[email protected]>,
Thor Lancelot Simon  <[email protected]> wrote:
>-=-=-=-=-=-
>
>The attached patch adds ioctls for multiple request submission and
>retrieval in a single system call, and for asynchronous operation via
>select()/poll() to /dev/crypto.  It was written for a slightly older
>NetBSD-current and I've hastily adapted it to Andrew's recent file
>descriptor allocation changes, which I hope I got right -- it's well
>tested before that adaptation but untested with it (caveat emptor).
>
>With this patch and a slightly clever multithreaded application that
>batches requests when pushing them to /dev/crypto we can do 84,000
>trivial asymmetric operations/sec (32 bit modular math ops) to a
>rather old crypto accellerator card, with a Core 2 Duo as the host.
>I think it's worth the added complexity.  Even simpler applications
>can benefit -- a lot -- from async operation and retrieving multiple
>requests at once when poll() fires.
>
>There is some duplicated code here in the multiple-request ioctls that
>could be shared with the single-request ioctls.  It'd be a moderate pain
>to clean up and I'd prefer to do that after commit so I can get this
>in the tree while I have time to focus on it.  Also, there is a large
>comment here describing the new ioctls and parameters which text I'll
>reproduce in or move to the manual page.
>
>I will revise the openssl engine to work as efficiently as possible with
>the new ioctls added here once I sort out some issues about updating
>OpenSSL itself in our tree and feeding changes back to the OpenSSL project
>in an effective way.
>
>Comments?

I think you left one bzero in there that should be converted to memset.

christos
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.