[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2c5bce16-eac4-a060-dbd8-62cc67df1bea@nvidia.com>
Date: Tue, 26 Apr 2022 09:08:35 +0300
From: Gal Pressman <gal@...dia.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: davem@...emloft.net, pabeni@...hat.com, netdev@...r.kernel.org,
borisp@...dia.com, john.fastabend@...il.com, daniel@...earbox.net,
vfedorenko@...ek.ru
Subject: Re: [PATCH net-next 08/10] tls: rx: use async as an in-out argument
On 25/04/2022 17:54, Jakub Kicinski wrote:
> On Mon, 25 Apr 2022 10:19:45 +0300 Gal Pressman wrote:
>> On 11/04/2022 22:19, Jakub Kicinski wrote:
>>> Propagating EINPROGRESS thru multiple layers of functions is
>>> error prone. Use darg->async as an in/out argument, like we
>>> use darg->zc today. On input it tells the code if async is
>>> allowed, on output if it took place.
>>>
>>> Signed-off-by: Jakub Kicinski <kuba@...nel.org>
>> I know this is not much to go on, but this patch broke our tls workflows
>> when device offload is enabled.
>> I'm still looking into it, but maybe you have an idea what might have
>> went wrong?
> Oof right, sorry. When packet is already decrypted by HW we'll skip
> the decrypt completely and leave async to whatever it was at input.
>
> Something like this?
>
> --->8---------
>
> diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
> index ddbe05ec5489..80094528eadb 100644
> --- a/net/tls/tls_sw.c
> +++ b/net/tls/tls_sw.c
> @@ -1562,6 +1562,7 @@ static int decrypt_skb_update(struct sock *sk, struct sk_buff *skb,
>
> if (tlm->decrypted) {
> darg->zc = false;
> + darg->async = false;
> return 0;
> }
>
> @@ -1572,6 +1573,7 @@ static int decrypt_skb_update(struct sock *sk, struct sk_buff *skb,
> if (err > 0) {
> tlm->decrypted = 1;
> darg->zc = false;
> + darg->async = false;
> goto decrypt_done;
> }
> }
Thank you Jakub!
I will run the patch you sent through our testing.
Powered by blists - more mailing lists