All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Maxim Mikityanskiy <maximmi@nvidia.com>
Cc: Boris Pismenny <borisp@nvidia.com>,
	John Fastabend <john.fastabend@gmail.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	"David S. Miller" <davem@davemloft.net>,
	Paolo Abeni <pabeni@redhat.com>, Tariq Toukan <tariqt@nvidia.com>,
	Aviad Yehezkel <aviadye@mellanox.com>,
	Ilya Lesokhin <ilyal@mellanox.com>,
	netdev@vger.kernel.org
Subject: Re: [PATCH net] tls: Skip tls_append_frag on zero copy size
Date: Fri, 22 Apr 2022 07:55:02 -0700	[thread overview]
Message-ID: <20220422075502.27532722@kernel.org> (raw)
In-Reply-To: <da984a08-1730-1b0c-d845-cf7ec732ba4c@nvidia.com>

On Thu, 21 Apr 2022 12:47:18 +0300 Maxim Mikityanskiy wrote:
> On 2022-04-18 17:56, Maxim Mikityanskiy wrote:
> > On 2022-04-14 13:28, Jakub Kicinski wrote:  
> >> I appreciate you're likely trying to keep the fix minimal but Greg
> >> always says "fix it right, worry about backports later".
> >>
> >> I think we should skip more, we can reorder the mins and if
> >> min(size, rec space) == 0 then we can skip the allocation as well.  
> > 
> > Sorry, I didn't get the idea. Could you elaborate?
> > 
> > Reordering the mins:
> > 
> > copy = min_t(size_t, size, max_open_record_len - record->len);
> > copy = min_t(size_t, copy, pfrag->size - pfrag->offset);
> > 
> > I assume by skipping the allocation you mean skipping 
> > tls_do_allocation(), right? Do you suggest to skip it if the result of 
> > the first min_t() is 0?
> > 
> > record->len used in the first min_t() comes from ctx->open_record, which 
> > either exists or is allocated by tls_do_allocation(). If we move the 
> > copy == 0 check above the tls_do_allocation() call, first we'll have to 
> > check whether ctx->open_record is NULL, which is currently checked by 
> > tls_do_allocation() itself.
> > 
> > If open_record is not NULL, there isn't much to skip in 
> > tls_do_allocation on copy == 0, the main part is already skipped, 
> > regardless of the value of copy. If open_record is NULL, we can't skip 
> > tls_do_allocation, and copy won't be 0 afterwards.
> > 
> > To compare, before (pseudocode):
> > 
> > tls_do_allocation {
> >      if (!ctx->open_record)
> >          ALLOCATE RECORD
> >          Now ctx->open_record is not NULL
> >      if (!sk_page_frag_refill(sk, pfrag))
> >          return -ENOMEM
> > }
> > handle errors from tls_do_allocation
> > copy = min(size, pfrag->size - pfrag->offset)
> > copy = min(copy, max_open_record_len - ctx->open_record->len)
> > if (copy)
> >      copy data and append frag
> > 
> > After:
> > 
> > if (ctx->open_record) {
> >      copy = min(size, max_open_record_len - ctx->open_record->len)
> >      if (copy) {
> >          // You want to put this part of tls_do_allocation under if (copy)?
> >          if (!sk_page_frag_refill(sk, pfrag))
> >              handle errors
> >          copy = min(copy, pfrag->size - pfrag->offset)
> >          if (copy)
> >              copy data and append frag
> >      }
> > } else {
> >      ALLOCATE RECORD
> >      if (!sk_page_frag_refill(sk, pfrag))
> >          handle errors
> >      // Have to do this after the allocation anyway.
> >      copy = min(size, max_open_record_len - ctx->open_record->len)
> >      copy = min(copy, pfrag->size - pfrag->offset)
> >      if (copy)
> >          copy data and append frag
> > }
> > 
> > Either I totally don't get what you suggested, or it doesn't make sense 
> > to me, because we have +1 branch in the common path when a record is 
> > open and copy is not 0, no changes when there is no record, and more 
> > repeating code hard to compress.
> > 
> > If I missed your idea, please explain in more details.  
> 
> Jakub, is your comment still relevant after my response? If not, can the 
> patch be merged?

I'd prefer if you refactored the code so tls_push_data() looks more
natural. But the patch is correct so if you don't want to you can
repost.

Sorry for the delay.

  reply	other threads:[~2022-04-22 14:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-13 13:49 [PATCH net] tls: Skip tls_append_frag on zero copy size Maxim Mikityanskiy
2022-04-14 10:28 ` Jakub Kicinski
2022-04-18 14:56   ` Maxim Mikityanskiy
2022-04-21  9:47     ` Maxim Mikityanskiy
2022-04-22 14:55       ` Jakub Kicinski [this message]
2022-04-26 15:48         ` Maxim Mikityanskiy

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=20220422075502.27532722@kernel.org \
    --to=kuba@kernel.org \
    --cc=aviadye@mellanox.com \
    --cc=borisp@nvidia.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=ilyal@mellanox.com \
    --cc=john.fastabend@gmail.com \
    --cc=maximmi@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=tariqt@nvidia.com \
    /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.