On Mon, Oct 11, 2010 at 7:54 PM, Phil Sutter <p...@nwl.cc> 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.
The way I countered this problem in a similar driver, I used an independent workqueue for the driver instead of scheduling on the global one. > 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. You built on the high level API of the driver. This is not that bad given the diversity of the linux-crypto internal API. A high level asynchronous API might be optimal, but the current implementation is fine as a start. regards, Nikos _______________________________________________ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
