On Sat, Oct 02, 2010 at 08:41:10AM +0200, Nikos Mavrogiannopoulos wrote: > On 10/01/2010 04:38 PM, Phil Sutter wrote: > > This time insertion and collection of asynchronous jobs is implemented > > via ioctl calls. > > Thanks it looks nice.
But it's all kippers and curtains. When testing an async-able speed.c on a multiprocessor system, interactivity went to zero. It seems like all these workqueue items do a really nice job at keeping the system busy enough to even ignore key presses most of the time. Another thing I realised as recently as when looking at the above problem is the internal workflow: asynchronous cryptoapi symbols, being called and waited upon from a single function in cryptodev (thereby making them synchronous), which are then used by my asynchronous userspace interface on top of everything. If that wasn't my own work, I'd call that the probably worst attempt possible. Looking at struct csession and how e.g. cryptodev_cipher_encrypt() works, there should be a way doing most of the work synchronously (i.e. everything up to and including the call to crypto_ablkcipher_encrypt()). This way I could also get rid of having to pass a copy of the current and current->mm objects around. > > What do you think about the preallocated list items? The implementation is > > flexible enough to allow for creating them right when they're needed (i.e. > > pcr->free becomes empty). Also, one could make the amount of (preallocated) > > items variable, similar to how get_userbuf() does with the struct page > > array. > > I like the idea of preallocated list items. An (high) upper limit should > always be present to prevent DoS[0]. > [0]. We can move those limits to a sysctl interface at a later point. Good point, will keep that in mind for future work at cryptodev. Greetings, Phil _______________________________________________ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
