On Wed, 2 Dec 2020 at 00:12, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > > 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. > One thing I realized just now is that in the current situation, all the synchronous skciphers already degrade like this. I.e., in Ben's case, without the special ccm implementation, ccm(aes) will resolve to ccm(ctr(aesni),cbcmac(aesni)), which is instantiated as a sync skcipher using the ctr and ccm/cbcmac templates built on top of the AES-NI cipher (not skcipher). This cipher will also fall back to suboptimal scalar code if the SIMD is in use in process context. > > 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
