On Wed, Nov 12, 2014 at 04:51:48PM +0800, Herbert Xu wrote: > On Wed, Nov 12, 2014 at 09:41:38AM +0100, Steffen Klassert wrote: > > > > Can't we just use cryptd unconditionally to fix this reordering problem? > > I think the idea is that most of the time cryptd isn't required > so we want to stick with direct processing to lower latency. Yes, I thought that. But is it really the case that doing it asynchronous increases the latency? I tried this some time ago and as far as I remember there was not too much difference between the direct and the asynchronous case. Might depend on the usecase of course. > > I think the simplest fix would be to punt to cryptd as long as > there are cryptd requests queued. This would be the second option. We may need to adjust the maximum cryptd queue lenght then, as the networking receive softirq might enqueue a lot of packets before cryptd can process them. -- 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
