On Tue, 1 Dec 2020 at 23:16, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, Dec 01, 2020 at 11:12:32PM +0100, Ard Biesheuvel wrote: > > > > What do you mean by just one direction? Ben just confirmed a > > The TX direction generally executes in process context, which > would benefit from an accelerated sync implementation. The RX > side on the other hand is always in softirq context. > Yes, and in both cases, irq_fpu_usable() will return true, unless RX and TX are running on the same core. > > substantial speedup for his use case, which requires the use of > > software encryption even on hardware that could support doing it in > > hardware, and that software encryption currently only supports the > > synchronous interface. > > 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. 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.
