On Wed, Dec 02, 2020 at 12:24:47AM +0100, Ard Biesheuvel wrote: > > 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) I don't think this makes sense. TX is typically done in response to RX so the natural alignment is for it to be on the same CPU. > 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. This sounds pretty tenuous. In any case, even if wireless itself doesn't get you, there could be loads running on top of it, for example, IPsec. > 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. We already have a framework for acceleration that works properly in aesni, I don't want to see us introduce another broken model within the same driver. So either just leave the whole thing along or do it properly by making wireless async. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
