Hey, On Wed, Oct 20, 2010 at 12:35:51PM +0200, Nikos Mavrogiannopoulos wrote: > On Wed, Oct 13, 2010 at 5:17 PM, Phil Sutter <phil.sut...@viprinet.com> wrote: > > Still ugly as hell (and therefore TODO): > > - having to pass task_struct and mm_struct from the calling process > > around > > - need to copy the IV right at write() time (copy_from_user seems to > > work in process context only) > > I'm still trying to find time to work on those. I think they are important > issue to be dealt before adding it.
Yes, me too. My solution introduces a struct kernel_crypt_op, containing a struct crypt_op and some other fields (amongst others the task_struct, mm_struct, IV and IV length). Looks fine so far, I'm currently sorting things a little for easier review, then submit the next version for review to the list. :) > > Depending on the chunk size, the throughput drops in a range between 80% > > and 7%. So if one can afford to wait for cryptodev, it's adviceable to > > also do so. > > I wonder why is that drop in performance? Did you test multiple submissions of > jobs or just a single one? Not really sure about that. On one hand there is the locking of the lists (although I managed to have that done quite efficiently), on the other hand userspace needs three syscalls (poll(), ioctl(CIOCASYNCCRYPT), ioctl(CIOCASYNCFETCH)) for a single operation instead of one. My async speed tester optimises that a little (polling for both POLLIN and POLLOUT, so a single poll() is used for fetching the last result and submitting the next job). And I should perhaps have mentioned that the given values were measured using the null-cipher test. With AES-128, the worst-case throughput is at about 40%, so not so bad at all. Besides having a bug somewhere, I don't care too much about the lower performance. The async-mode is useful mainly for programs doing other stuff at the same time, in which case having to wait for each crypto operation to complete before being able to do anything else should be such a PITA that performance is actually higher using the async interface. Hmm, I can't wait for Herbert's interface to getting finished. The plan is still to adjust speed.c for using it and to compare the throughput. Just to be able to say: "you got it exactly how you wanted it, and look here, it sucks". :) Greetings, Phil -- Viprinet GmbH Mainzer Str. 43 55411 Bingen am Rhein Germany Zentrale: +49-6721-49030-0 Durchwahl: +49-6721-49030-134 Fax: +49-6721-49030-209 phil.sut...@viprinet.com http://www.viprinet.com Sitz der Gesellschaft: Bingen am Rhein Handelsregister: Amtsgericht Mainz HRB40380 Geschäftsführer: Simon Kissel _______________________________________________ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
