From: Wenjia Zhang <wenjia@linux.ibm.com>
To: Guangguan Wang <guangguan.wang@linux.alibaba.com>,
jaka@linux.ibm.com, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com
Cc: kgraul@linux.ibm.com, alibuda@linux.alibaba.com,
tonylu@linux.alibaba.com, guwen@linux.alibaba.com,
linux-s390@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 0/2] Change the upper boundary of SMC-R's snd_buf and rcv_buf to 512MB
Date: Wed, 29 May 2024 18:28:33 +0200 [thread overview]
Message-ID: <328ea674-0904-4c81-a6e2-7be3420ad578@linux.ibm.com> (raw)
In-Reply-To: <20240528135138.99266-1-guangguan.wang@linux.alibaba.com>
On 28.05.24 15:51, Guangguan Wang wrote:
> SMCR_RMBE_SIZES is the upper boundary of SMC-R's snd_buf and rcv_buf.
> The maximum bytes of snd_buf and rcv_buf can be calculated by 2^SMCR_
> RMBE_SIZES * 16KB. SMCR_RMBE_SIZES = 5 means the upper boundary is 512KB.
> TCP's snd_buf and rcv_buf max size is configured by net.ipv4.tcp_w/rmem[2]
> whose defalut value is 4MB or 6MB, is much larger than SMC-R's upper
> boundary.
>
> In some scenarios, such as Recommendation System, the communication
> pattern is mainly large size send/recv, where the size of snd_buf and
> rcv_buf greatly affects performance. Due to the upper boundary
> disadvantage, SMC-R performs poor than TCP in those scenarios. So it
> is time to enlarge the upper boundary size of SMC-R's snd_buf and rcv_buf,
> so that the SMC-R's snd_buf and rcv_buf can be configured to larger size
> for performance gain in such scenarios.
>
> The SMC-R rcv_buf's size will be transferred to peer by the field
> rmbe_size in clc accept and confirm message. The length of the field
> rmbe_size is four bits, which means the maximum value of SMCR_RMBE_SIZES
> is 15. In case of frequently adjusting the value of SMCR_RMBE_SIZES
> in different scenarios, set the value of SMCR_RMBE_SIZES to the maximum
> value 15, which means the upper boundary of SMC-R's snd_buf and rcv_buf
> is 512MB. As the real memory usage is determined by the value of
> net.smc.w/rmem, not by the upper boundary, set the value of SMCR_RMBE_SIZES
> to the maximum value has no side affects.
>
Hi Guangguan,
That is correct that the maximum buffer(snd_buf and rcv_buf) size of
SMCR is much smaller than TCP's. If I remember correctly, that was
because the 512KB was enough for the traffic and did not waist memory
space after some experiment. Sure, that was years ago, and it could be
very different nowadays. But I'm still curious if you have any concrete
scenario with performance benchmark which shows the distinguish
disadvantage of the current maximum buffer size.
Thanks,
Wenjia
> Guangguan Wang (2):
> net/smc: set rmb's SG_MAX_SINGLE_ALLOC limitation only when
> CONFIG_ARCH_NO_SG_CHAIN is defined
> net/smc: change SMCR_RMBE_SIZES from 5 to 15
>
> net/smc/smc_core.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
next prev parent reply other threads:[~2024-05-29 16:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-28 13:51 [PATCH net-next 0/2] Change the upper boundary of SMC-R's snd_buf and rcv_buf to 512MB Guangguan Wang
2024-05-28 13:51 ` [PATCH net-next 1/2] net/smc: set rmb's SG_MAX_SINGLE_ALLOC limitation only when CONFIG_ARCH_NO_SG_CHAIN is defined Guangguan Wang
2024-06-01 8:35 ` Simon Horman
2024-06-03 2:21 ` Guangguan Wang
2024-05-28 13:51 ` [PATCH net-next 2/2] net/smc: change SMCR_RMBE_SIZES from 5 to 15 Guangguan Wang
2024-05-29 16:28 ` Wenjia Zhang [this message]
2024-05-31 8:15 ` [PATCH net-next 0/2] Change the upper boundary of SMC-R's snd_buf and rcv_buf to 512MB Guangguan Wang
2024-05-31 9:03 ` Wenjia Zhang
2024-05-31 9:35 ` Guangguan Wang
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=328ea674-0904-4c81-a6e2-7be3420ad578@linux.ibm.com \
--to=wenjia@linux.ibm.com \
--cc=alibuda@linux.alibaba.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=guangguan.wang@linux.alibaba.com \
--cc=guwen@linux.alibaba.com \
--cc=jaka@linux.ibm.com \
--cc=kgraul@linux.ibm.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=tonylu@linux.alibaba.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox