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 changed padata to use workqueues instead of softirqs to do the parallelization/serialization. The performance for IPsec is similar to the softirq version, so probaply we don't need to use softirqs at all. While thinking about using workqueues for padata/pcrypt, I noticed two problems if we return asynchronous in thread context from the crypto-layer to xfrm. Returning in thread context is not new with pcrypt, we also can return in thread context if we use the cryptd. If we use tunnel mode, xfrm_input() calls netif_rx() which is certainly wrong if we are in thread context, we need to call netif_rx_ni() instead. Also xfrm_input() uses bare spinlocks to protect the xfrm_state, this is not appropriate in this case. We probaply need to switch off the bottom halves, if we allow to return from the cypto-layer in softirq and thread context. Any thoughts on how to handle this? -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
