All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vakul Garg <vakul.garg@nxp.com>
To: Dave Watson <davejwatson@fb.com>, David Miller <davem@davemloft.net>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"borisp@mellanox.com" <borisp@mellanox.com>,
	"aviadye@mellanox.com" <aviadye@mellanox.com>,
	Doron Roberts-Kedes <doronrk@fb.com>
Subject: RE: [net-next v5 3/3] net/tls: Remove redundant array allocation.
Date: Tue, 24 Jul 2018 08:22:02 +0000	[thread overview]
Message-ID: <DB7PR04MB4252EC95B89517727D6F51478B550@DB7PR04MB4252.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <20180723163509.GA91424@davejwatson-mba.local>



> -----Original Message-----
> From: Dave Watson [mailto:davejwatson@fb.com]
> Sent: Monday, July 23, 2018 10:05 PM
> To: David Miller <davem@davemloft.net>
> Cc: Vakul Garg <vakul.garg@nxp.com>; netdev@vger.kernel.org;
> borisp@mellanox.com; aviadye@mellanox.com; Doron Roberts-Kedes
> <doronrk@fb.com>
> Subject: Re: [net-next v5 3/3] net/tls: Remove redundant array allocation.
> 
> On 07/21/18 07:25 PM, David Miller wrote:
> > From: Vakul Garg <vakul.garg@nxp.com>
> > Date: Thu, 19 Jul 2018 21:56:13 +0530
> >
> > > In function decrypt_skb(), array allocation in case when sgout is
> > > NULL is unnecessary. Instead, local variable sgin_arr[] can be used.
> > >
> > > Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
> >
> > Hmmm...
> >
> > Dave, can you take a look at this?  Do you think there might have been
> > a reason you felt that you needed to dynamically allocate the
> > scatterlists when you COW and skb and do in-place decryption?
> >
> > I guess this change is ok, nsg can only get smaller when the SKB is
> > COW'd.
> >
> 
> > >         memcpy(iv, tls_ctx->rx.iv, TLS_CIPHER_AES_GCM_128_SALT_SIZE);
> > >         if (!sgout) {
> > >                 nsg = skb_cow_data(skb, 0, &unused) + 1;
> > > -               sgin = kmalloc_array(nsg, sizeof(*sgin), sk->sk_allocation);
> > >                 sgout = sgin;
> > >         }
> 
> I don't think this patch is safe as-is.  sgin_arr is a stack array of size
> MAX_SKB_FRAGS (+ overhead), while my read of skb_cow_data is that it
> walks the whole chain of skbs from skb->next, and can return any number of
> segments.  Therefore we need to heap allocate.  I think I copied the IPSEC
> code here.
> 
> For perf though, we could use the stack array if skb_cow_data returns <=
> MAX_SKB_FRAGS.
> 
> This code is slightly confusing though, since we don't heap allocate in the
> zerocopy case - what happens is that skb_to_sgvec returns -EMSGSIZE, and
> we fall back to the non-zerocopy case, and return again to this function,
> where we then hit the skb_cow_data path and heap allocate.

Thanks for explaining. 
I am missing the point why MAX_SKB_FRAGS sized local array 
sgin has been used in tls_sw_recvmsg(). What is special about MAX_SKB_FRAGS so
that we used it as a size factor for 'sgin'?

Will it be a bad idea to get rid of array 'sgin' on stack and simply kmalloc 'sgin' for 
whatever the number the number of pages returned by iov_iter_npages()?
We can allocate for sgout too with the same kmalloc().

(Using a local array based 'sgin' is coming in the way to achieve sending multiple async
record decryption requests to the accelerator without waiting for previous one to complete.)
 

  parent reply	other threads:[~2018-07-24  9:27 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-19 16:26 [net-next v5 0/3] net/tls: Minor code cleanup patches Vakul Garg
2018-07-19 16:26 ` [net-next v5 1/3] net/tls: Use socket data_ready callback on record availability Vakul Garg
2018-07-19 16:26 ` [net-next v5 2/3] net/tls: Remove redundant variable assignments and wakeup Vakul Garg
2018-07-19 16:26 ` [net-next v5 3/3] net/tls: Remove redundant array allocation Vakul Garg
2018-07-22  2:25   ` David Miller
2018-07-23 16:35     ` Dave Watson
2018-07-24  4:41       ` David Miller
2018-07-24  4:43         ` Vakul Garg
2018-07-24  4:49           ` David Miller
2018-07-24  8:22       ` Vakul Garg [this message]
2018-07-25 21:01         ` Dave Watson
2018-07-27  9:34           ` Vakul Garg
2018-07-27 15:38             ` Dave Watson
2018-08-01 13:49       ` Vakul Garg
2018-08-01 20:52         ` Dave Watson
  -- strict thread matches above, loose matches on Subject: below --
2018-07-19 16:23 [net-next v4 0/3] net/tls: Minor code cleanup patches Vakul Garg
2018-07-19 16:23 ` [net-next v5 3/3] net/tls: Remove redundant array allocation Vakul Garg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DB7PR04MB4252EC95B89517727D6F51478B550@DB7PR04MB4252.eurprd04.prod.outlook.com \
    --to=vakul.garg@nxp.com \
    --cc=aviadye@mellanox.com \
    --cc=borisp@mellanox.com \
    --cc=davejwatson@fb.com \
    --cc=davem@davemloft.net \
    --cc=doronrk@fb.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.