On Thu, 15 Dec 2022 at 11:27, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > > On Wed, Dec 7, 2022 at 11:39 AM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > We currently only permit kernel mode NEON in process context, to avoid > > the need to preserve/restore the NEON register file when taking an > > exception while running in the kernel. > > > > Like we did on arm64, we can relax this restriction substantially, by > > permitting kernel mode NEON from softirq context, while ensuring that > > softirq processing is disabled when the NEON is being used in task > > context. This guarantees that only NEON context belonging to user space > > needs to be preserved and restored, which is already taken care of. > > > > This is especially relevant for network encryption, where incoming > > frames are typically handled in softirq context, and deferring software > > decryption to a kernel thread or falling back to C code are both > > undesirable from a performance PoV. > > > > Signed-off-by: Ard Biesheuvel <ardb@xxxxxxxxxx> > > So boosting WireGuard as primary SW network encryption user? Essentially, although the use case that inspired this work is related to IPsec not WireGuard, and the crypto algorithm in that case (GCM) is ~3x faster than WG's chacha20poly1305, which makes the performance overhead of asynchronous completion even more significant. (Note that GCM needs the AES and PMULL instructions which are usually only available when running the 32-bit kernel on a 64-bit core, whereas chacha20poly1305 uses ordinary NEON instructions.) But Martin responded with a Tested-by regarding chacha20poly1305 on IPsec (not WG) where there is also a noticeable speedup, so WG on ARM32 should definitely benefit from this as well. > This is really neat, BTW: > Reviewed-by: Linus Walleij <linus.walleij@xxxxxxxxxx> > Thanks!
