From: Gerd Bayer <gbayer@linux.ibm.com>
To: Wenjia Zhang <wenjia@linux.ibm.com>,
Jan Karcher <jaka@linux.ibm.com>,
Tony Lu <tonylu@linux.alibaba.com>,
Paolo Abeni <pabeni@redhat.com>
Cc: Karsten Graul <kgraul@linux.ibm.com>,
"D . Wythe" <alibuda@linux.alibaba.com>,
Wen Gu <guwen@linux.alibaba.com>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
linux-s390@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [PATCH net v3 0/2] net/smc: Fix effective buffer size
Date: Fri, 4 Aug 2023 19:06:22 +0200 [thread overview]
Message-ID: <20230804170624.940883-1-gbayer@linux.ibm.com> (raw)
Hi all,
commit 0227f058aa29 ("net/smc: Unbind r/w buffer size from clcsock
and make them tunable") started to derive the effective buffer size for
SMC connections inconsistently in case a TCP fallback was used and
memory consumption of SMC with the default settings was doubled when
a connection negotiated SMC. That was not what we want.
This series consolidates the resulting effective buffer size that is
used with SMC sockets, which is based on Jan Karcher's effort (see
[1]). For all TCP exchanges (in particular in case of a fall back when
no SMC connection was possible) the values from net.ipv4.tcp_[rw]mem
are used. If SMC succeeds in establishing a SMC connection, the newly
introduced values from net.smc.[rw]mem are used.
net.smc.[rw]mem is initialized to 64kB, respectively. Internal test
have show this to be a good compromise between throughput/latency
and memory consumption. Also net.smc.[rw]mem is now decoupled completely
from any tuning through net.ipv4.tcp_[rw]mem.
If a user chose to tune a socket's receive or send buffer size with
setsockopt, this tuning is now consistently applied to either fall-back
TCP or proper SMC connections over the socket.
Thanks,
Gerd
v2 - v3:
- Rebase to and resolve conflict of second patch with latest net/master.
v1 - v2:
- In second patch, use sock_net() helper as suggested by Tony and demanded
by kernel test robot.
Gerd Bayer (2):
net/smc: Fix setsockopt and sysctl to specify same buffer size again
net/smc: Use correct buffer sizes when switching between TCP and SMC
net/smc/af_smc.c | 77 ++++++++++++++++++++++++++++++--------------
net/smc/smc.h | 2 +-
net/smc/smc_clc.c | 4 +--
net/smc/smc_core.c | 25 +++++++-------
net/smc/smc_sysctl.c | 10 ++++--
5 files changed, 76 insertions(+), 42 deletions(-)
base-commit: 1733d0be68ab1b89358a3b0471ef425fd61de7c5
--
2.41.0
next reply other threads:[~2023-08-04 17:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-04 17:06 Gerd Bayer [this message]
2023-08-04 17:06 ` [PATCH net v3 1/2] net/smc: Fix setsockopt and sysctl to specify same buffer size again Gerd Bayer
2023-08-04 17:06 ` [PATCH net v3 2/2] net/smc: Use correct buffer sizes when switching between TCP and SMC Gerd Bayer
2023-08-09 10:30 ` [PATCH net v3 0/2] net/smc: Fix effective buffer size patchwork-bot+netdevbpf
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=20230804170624.940883-1-gbayer@linux.ibm.com \
--to=gbayer@linux.ibm.com \
--cc=alibuda@linux.alibaba.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.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 \
--cc=wenjia@linux.ibm.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;
as well as URLs for NNTP newsgroup(s).