[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180803002648.GA2708@doronrk-mbp.dhcp.thefacebook.com>
Date: Thu, 2 Aug 2018 17:26:48 -0700
From: Doron Roberts-Kedes <doronrk@...com>
To: Dave Watson <davejwatson@...com>
CC: Vakul Garg <vakul.garg@....com>, <netdev@...r.kernel.org>,
<borisp@...lanox.com>, <aviadye@...lanox.com>,
<davem@...emloft.net>
Subject: Re: [PATCH net-next] net/tls: Always get number of sg entries for
skb to be decrypted
On Thu, Aug 02, 2018 at 09:50:58AM -0700, Dave Watson wrote:
> On 08/02/18 09:50 PM, Vakul Garg wrote:
> > Function decrypt_skb() made a bad assumption that number of sg entries
> > required for mapping skb to be decrypted would always be less than
> > MAX_SKB_FRAGS. The required count of sg entries for skb should always be
> > calculated. If they cannot fit in local array sgin_arr[], allocate them
> > from heap irrespective whether it is zero-copy case or otherwise. The
> > change also benefits the non-zero copy case as we could use sgin_arr[]
> > instead of always allocating sg entries from heap.
> >
> > Signed-off-by: Vakul Garg <vakul.garg@....com>
>
> Looks great, thanks.
>
> Reviewed-by: Dave Waston <davejwatson@...com>
I agree that this is a problem, but I'm not sure that this is the best
way to fix it. Calling skb_cow_data unconditionally is expensive. In my
benchmarks this patch cause a 5% CPU regression, all from memcpy from
skb_cow_data, and a 15% regression in encrypted NBD IOPS. It is possible
to calculate the number of scatterlist elements required to map the skb
without invoking skb_cow_data. I'll have a patch up shortly.
Powered by blists - more mailing lists