On Mon, Jun 10, 2019 at 1:02 PM Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > On Mon, 10 Jun 2019 at 19:54, Steve French <smfrench@xxxxxxxxx> wrote: > > Yes - when I tested the GCM code in cifs.ko last week (the two patches > > are currently > > in the cifs-2.6.git for-next branch and thus in linux-next and are > > attached), I was astounded > > at the improvement - encryption with GCM is now faster than signing, <snip> > I assume this was tested on high end x86 silicon? The CBCMAC path in > CCM is strictly sequential, so on systems with deep pipelines, you > lose a lot of speed there. For arm64, I implemented a CCM driver that > does the encryption and authentication in parallel, which mitigates > most of the performance hit, but even then, you will still be running > with a underutilized pipeline (unless you are using low end silicon > which only has a 2 cycle latency for AES instructions) Was doing most of my testing on an i7-7820HQ 2.9GHz (passmark score 9231) > > Any other ideas how to improve the encryption or signing in the read > > or write path > > in cifs.ko would be appreciated. We still are slower than Windows, probably in > > part due to holding mutexes longer in sending the frame across the network > > (including signing or encryption) which limits parallelism somewhat. > > > > It all depends on whether crypto is still the bottleneck in this case. Trying to wade through traces to see. Unfortunately lots of different configurations (especially varying network latency and network copy offload) to experiment with. -- Thanks, Steve
