On Mon, 10 Jun 2019 at 19:54, Steve French <smfrench@xxxxxxxxx> wrote: > > On Mon, Jun 10, 2019 at 11:17 AM Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > > > Hi Steve, > > > > On Sun, Jun 09, 2019 at 05:03:25PM -0500, Steve French wrote: > > > Probably harmless to change this code path (build_ntlmssp_auth_blob is > > > called at session negotiation time so shouldn't have much of a > > > performance impact). > > > > > > On the other hand if we can find optimizations in the encryption and > > > signing paths, that would be really helpful. There was a lot of > > > focus on encryption performance at SambaXP last week. > > > > > > Andreas from Redhat gave a talk on the improvements in Samba with TLS > > > implementation of AES-GCM. I added the cifs client implementation of > > > AES-GCM and notice it is now faster to encrypt packets than sign them > > > (performance is about 2 to 3 times faster now with GCM). > > > > > > On Sun, Jun 9, 2019 at 6:57 AM Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > > > > > > > > The CIFS code uses the sync skcipher API to invoke the ecb(arc4) skcipher, > > > > of which only a single generic C code implementation exists. This means > > > > that going through all the trouble of using scatterlists etc buys us > > > > very little, and we're better off just invoking the arc4 library directly. > > > > This patch only changes RC4 encryption, and to be clear it actually *improves* > > the performance of the RC4 encryption, since it removes unnecessary > > abstractions. I'd really hope that people wouldn't care either way, though, > > since RC4 is insecure and should not be used. > > > > Also it seems that fs/cifs/ supports AES-CCM but not AES-GCM? > > > > /* pneg_ctxt->Ciphers[0] = SMB2_ENCRYPTION_AES128_GCM;*/ /* not supported yet */ > > pneg_ctxt->Ciphers[0] = SMB2_ENCRYPTION_AES128_CCM; > > > > AES-GCM is usually faster than AES-CCM, so if you want to improve performance, > > switching from CCM to GCM would do that. > > > > - Eric > > 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, > and copy is more > than twice as fast as encryption was before with CCM (assuming a fast > enough network so > that the network is not the bottleneck). We see more benefit in the write path > (copy to server) than the read path (copy from server) but even the > read path gets > 80% benefit in my tests, and with the addition of multichannel support > in the next > few months, we should see copy from server on SMB3.1.1 mounts > improving even more. > 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) > 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.
