All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lu <tonylu@linux.alibaba.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: kgraul@linux.ibm.com, davem@davemloft.net,
	netdev@vger.kernel.org, linux-s390@vger.kernel.org,
	linux-rdma@vger.kernel.org
Subject: Re: [PATCH net] net/smc: Clear memory when release and reuse buffer
Date: Fri, 3 Dec 2021 11:47:22 +0800	[thread overview]
Message-ID: <YamTSiiDp2mpeaXc@TonyMac-Alibaba> (raw)
In-Reply-To: <20211126112855.37274cb7@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

On Fri, Nov 26, 2021 at 11:28:55AM -0800, Jakub Kicinski wrote:
> On Thu, 25 Nov 2021 20:28:59 +0800 Tony Lu wrote:
> > Currently, buffers are clear when smc create connections and reuse
> > buffer. It will slow down the speed of establishing new connection. In
> > most cases, the applications hope to establish connections as quickly as
> > possible.
> > 
> > This patch moves memset() from connection creation path to release and
> > buffer unuse path, this trades off between speed of establishing and
> > release.
> > 
> > Test environments:
> > - CPU Intel Xeon Platinum 8 core, mem 32 GiB, nic Mellanox CX4
> > - socket sndbuf / rcvbuf: 16384 / 131072 bytes
> > - w/o first round, 5 rounds, avg, 100 conns batch per round
> > - smc_buf_create() use bpftrace kprobe, introduces extra latency
> > 
> > Latency benchmarks for smc_buf_create():
> >   w/o patch : 19040.0 ns
> >   w/  patch :  1932.6 ns
> >   ratio :        10.2% (-89.8%)
> > 
> > Latency benchmarks for socket create and connect:
> >   w/o patch :   143.3 us
> >   w/  patch :   102.2 us
> >   ratio :        71.3% (-28.7%)
> > 
> > The latency of establishing connections is reduced by 28.7%.
> > 
> > Signed-off-by: Tony Lu <tonylu@linux.alibaba.com>
> > Reviewed-by: Wen Gu <guwen@linux.alibaba.com>
> 
> The tag in the subject seems incorrect, we tag things as [PATCH net] 
> if they are fixes, and as [PATCH net-next] if they are new features,
> code refactoring or performance improvements.
> 
> Is this a fix for a regression? In which case we need a Fixes tag to
> indicate where it was introduced. Otherwise it needs to be tagged as
> [PATCH net-next].
> 
> I'm assuming Karsten will take it via his tree, otherwise you'll need
> to repost.

Sorry to miss Graul’s email, he said he would put it in his own tree. I
would send v2 out if he needed. Thank you.

Thanks,
Tony Lu

      parent reply	other threads:[~2021-12-03  3:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-25 12:28 [PATCH net] net/smc: Clear memory when release and reuse buffer Tony Lu
2021-11-26 19:28 ` Jakub Kicinski
2021-11-28 21:42   ` Karsten Graul
2021-11-30  2:52   ` Tony Lu
2021-12-02 14:23     ` Karsten Graul
2021-12-03  3:31       ` Tony Lu
2021-12-03  7:23         ` Karsten Graul
2021-12-03  3:47   ` Tony Lu [this message]

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=YamTSiiDp2mpeaXc@TonyMac-Alibaba \
    --to=tonylu@linux.alibaba.com \
    --cc=davem@davemloft.net \
    --cc=kgraul@linux.ibm.com \
    --cc=kuba@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --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.