On Tuesday, October 31, 2017 11:14 AM Steffen Klassert wrote:

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. 

You are correct.

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.

Are you sure supporting ASYNC crypto for fallback is worth the trouble?
This path is going to be slower that the path were you do the crypto in advance, right?

Are you concerned about the lack of synchronous crypto implementations for some algorithms?