On Tue, Oct 31, 2017 at 03:44:38PM +0800, Herbert Xu wrote: > On Tue, Oct 31, 2017 at 07:39:08AM +0000, Ilya Lesokhin wrote: > > > > I think we should consider having a synchronous implementation that falls > > back > > to integer implementation when the FPU is not available. > > This would spare the users from having to handle the asynchronous case. > > > > Hopefully the situation where the FPU is not available is rare enough > > So it won't hurt the performance too much. > > For your intended use case I think async processing should work just > fine as it does for IPsec.
I think Ilya talks about the case where the TLS crypto is intended to be offloaded to a NIC. In this case we need a software crypto fallback e.g. if a packet got rerouted to a device that does not support crypto offloading. For IPsec, we catch these cases in validate_xmit_skb() either with the ESP GSO handler, or in the non GSO case with validate_xmit_xfrm(). We currently request for a sync algorithm to avoid the async handling for this case. Allowing for async crypto would require some way to handle async returnes or the -EBUSY case from the crypto layer inside of a qdisc. Also, in the GSO case it is not clear how to unwind the GSO call stack on a async return. I had a discussion with davem at the netfilter workshop about this. Based on this discussion, I prepared some patches that I hope to be (RFC) ready until the netdev2.2 next week.