> -----Original Message----- > From: Dave Watson [mailto:davejwat...@fb.com] > Sent: Wednesday, August 15, 2018 10:26 PM > To: Vakul Garg <vakul.g...@nxp.com> > Cc: netdev@vger.kernel.org; bor...@mellanox.com; > avia...@mellanox.com; da...@davemloft.net > Subject: Re: [PATCH net-next][RFC] net/tls: Add support for async decryption > of tls records > > On 08/14/18 07:47 PM, Vakul Garg wrote: > > Incoming TLS records which are directly decrypted into user space > > application buffer i.e. records which are decrypted in zero-copy mode > > are submitted for async decryption. When the decryption cryptoapi > > returns -EINPROGRESS, the next tls record is parsed and then submitted > > for decryption. The references to records which has been sent for > > async decryption are dropped. This happens in a loop for all the > > records that can be decrypted in zero-copy mode. For records for which > > decryption is not possible in zero-copy mode, asynchronous decryption > > is not used and we wait for decryption crypto api to complete. > > > > For crypto requests executing in async fashion, the memory for > > aead_request, sglists and skb etc is freed from the decryption > > completion handler. The decryption completion handler wakesup the > > sleeping user context. This happens when the user context is done > > enqueueing all the crypto requests and is waiting for all the async > > operations to finish. Since the splice() operation does not use > > zero-copy decryption, async remains disabled for splice(). > > I found it a little hard to understand what you are trying to do based on the > commit message. Ok, I will rewrite it.
> Reading the code, it looks like if the recv() spans multiple > TLS records, we will start decryption on all of them, and only wait right > before recv() returns, yes? This approach sounds great to me. > Yes, that's the idea. I am firing as many decryption jobs as possible till I run out of user application provided buffer space. > Three of the selftests are failing for me: > > [ FAIL ] tls.recv_partial > [ FAIL ] tls.recv_peek > [ FAIL ] tls.recv_peek_multiple Will look into it. Thanks for spending time in review my patch. The patch is showing good performance benefits.
