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?
