On Wed, 2 Dec 2020 at 00:30, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > > 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. > You just explained that TX typically runs in process context, whereas RX is handled in softirq context. So how exactly are these going to end up on the same core? > > 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. > Yes, but IPsec will not use the synchronous interface. > > 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. > Fair enough. But it is unfortunate that we cannot support Ben's use case without a lot of additional work that serves no purpose otherwise.
