On Thu, Oct 08, 2009 at 11:18:33PM -0700, David Miller wrote: > > Steffen are we going to end up adding a softirq for every crypto > transform type? > > That won't work, softirqs are to be scarcely allocated and operate > at a very high level. > > I can think of two alternatives: > > 1) One softirq that does per-cpu padata work via some generic > callout mechanism.
I tried already to reduce the softirqs by using the same softirq for encryption and decryption. But in case of IPsec this had a negative performance impact. So if we stay with softirqs we would probaply need at least two for the whole crypto layer. Best would be if we would not need softirqs at all. In fact I started with a thread based version but the thread based version had never that performance like the softirq version has. Anyway, in between the workqueue interface changed so perhaps it is worth to try again with workqueues. > > 2) Use tasklets > Tasklets are not sufficient because I can't control on which cpu the tasklet will run on. Also we can run just one tasklet of the same type the time, so tasklets don't parallelize. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
