On Tue, Dec 01, 2020 at 11:27:52PM +0100, Ard Biesheuvel wrote: > > > The problem is that the degradation would come at the worst time, > > when the system is loaded. IOW when you get an interrupt during > > your TX path and get RX traffic that's when you'll take the fallback > > path. > > I can see how in the general case, this is something you would prefer > to avoid. However, on SMP x86_64 systems that implement AES-NI (which > runs at ~1 cycle per byte), I don't see this as a real problem for > this driver. AES-NI is 1 cycle per byte but the fallback is not. > What we could do is expose both versions, where the async version has > a slightly higher priority, so that all users that do support the > async interface will get it, and the wifi stack can use the sync > interface instead. No we've already tried this with IPsec and it doesn't work. That's why the async path exists in aesni. Wireless is no different to IPsec in this respect. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
