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. > True. But the fallback only gets executed if the scheduler is stupid enough to schedule the TX task onto the core that is overloaded doing RX softirqs. So in the general case, both TX and RX will be using AES-NI instructions (unless the CCMP is done in hardware which is the most common case by far) > > 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. > Wireless is very different. Wifi uses a medium that is fundamentally shared, and so the load it can induce is bounded. There is no way a wifi interface is going to saturate a 64-bit AES-NI core doing CCMP in software. Given the above, can't we be pragmatic here? This code addresses a niche use case, which is not affected by the general concerns regarding async crypto.
