[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DB7PR04MB425234183E9EE101711403008B0D0@DB7PR04MB4252.eurprd04.prod.outlook.com>
Date: Sun, 2 Sep 2018 02:28:00 +0000
From: Vakul Garg <vakul.garg@....com>
To: David Miller <davem@...emloft.net>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"borisp@...lanox.com" <borisp@...lanox.com>,
"aviadye@...lanox.com" <aviadye@...lanox.com>,
"davejwatson@...com" <davejwatson@...com>
Subject: RE: [PATCH net-next v2] net/tls: Add support for async decryption of
tls records
> -----Original Message-----
> From: David Miller <davem@...emloft.net>
> Sent: Saturday, September 1, 2018 6:31 AM
> To: Vakul Garg <vakul.garg@....com>
> Cc: netdev@...r.kernel.org; borisp@...lanox.com;
> aviadye@...lanox.com; davejwatson@...com
> Subject: Re: [PATCH net-next v2] net/tls: Add support for async decryption of
> tls records
>
> From: Vakul Garg <vakul.garg@....com>
> Date: Wed, 29 Aug 2018 15:26:55 +0530
>
> > When tls records are decrypted using asynchronous acclerators such as
> > NXP CAAM engine, the crypto apis return -EINPROGRESS. Presently, on
> > getting -EINPROGRESS, the tls record processing stops till the time
> > the crypto accelerator finishes off and returns the result. This
> > incurs a context switch and is not an efficient way of accessing the
> > crypto accelerators. Crypto accelerators work efficient when they are
> > queued with multiple crypto jobs without having to wait for the
> > previous ones to complete.
> >
> > The patch submits multiple crypto requests without having to wait for
> > for previous ones to complete. This has been implemented for records
> > which are decrypted in zero-copy mode. At the end of recvmsg(), we
> > wait for all the asynchronous decryption requests to complete.
> >
> > The references to records which have been sent for async decryption
> > are dropped. For cases where record 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 when recvmsg() flags that it has done sending
> > all the decryption requests and there are no more decryption requests
> > pending to be completed.
> >
> > Signed-off-by: Vakul Garg <vakul.garg@....com>
> > Reviewed-by: Dave Watson <davejwatson@...com>
> > ---
> >
> > Changes since v1:
> > - Simplified recvmsg() so to drop reference to skb in case it
> > was submimtted for async decryption.
> > - Modified tls_sw_advance_skb() to handle case when input skb is
> > NULL.
>
> Applied.
I do not find this patch in tree yet.
Can you please check? Thanks and Regards.
Powered by blists - more mailing lists