From: "D. Wythe" <alibuda@linux.alibaba.com>
To: kgraul@linux.ibm.com, wenjia@linux.ibm.com, jaka@linux.ibm.com
Cc: kuba@kernel.org, davem@davemloft.net, netdev@vger.kernel.org,
linux-s390@vger.kernel.org, linux-rdma@vger.kernel.org
Subject: Re: [PATCH net-next v5 00/10] optimize the parallelism of SMC-R connections
Date: Thu, 24 Nov 2022 13:55:37 +0800 [thread overview]
Message-ID: <c98a8f04-c696-c9e0-4d7e-bc31109a0e04@linux.alibaba.com> (raw)
In-Reply-To: <1669218890-115854-1-git-send-email-alibuda@linux.alibaba.com>
On 11/23/22 11:54 PM, D.Wythe wrote:
> From: "D.Wythe" <alibuda@linux.alibaba.com>
>
> This patch set attempts to optimize the parallelism of SMC-R connections,
> mainly to reduce unnecessary blocking on locks, and to fix exceptions that
> occur after thoses optimization.
>
> D. Wythe (10):
> net/smc: Fix potential panic dues to unprotected
> smc_llc_srv_add_link()
> net/smc: fix application data exception
> net/smc: fix SMC_CLC_DECL_ERR_REGRMB without smc_server_lgr_pending
> net/smc: remove locks smc_client_lgr_pending and
> smc_server_lgr_pending
> net/smc: allow confirm/delete rkey response deliver multiplex
> net/smc: make SMC_LLC_FLOW_RKEY run concurrently
> net/smc: llc_conf_mutex refactor, replace it with rw_semaphore
> net/smc: use read semaphores to reduce unnecessary blocking in
> smc_buf_create() & smcr_buf_unuse()
> net/smc: reduce unnecessary blocking in smcr_lgr_reg_rmbs()
> net/smc: replace mutex rmbs_lock and sndbufs_lock with rw_semaphore
>
> net/smc/af_smc.c | 74 ++++----
> net/smc/smc_core.c | 541 +++++++++++++++++++++++++++++++++++++++++++++++------
> net/smc/smc_core.h | 53 +++++-
> net/smc/smc_llc.c | 285 ++++++++++++++++++++--------
> net/smc/smc_llc.h | 6 +
> net/smc/smc_wr.c | 10 -
> net/smc/smc_wr.h | 10 +
> 7 files changed, 801 insertions(+), 178 deletions(-)
>
Hi Jan and Wenjia,
I'm wondering whether the bug fix patches need to be put together in this series. I'm considering
sending these bug fix patches separately now, which may be better, in case that our patch
might have other problems. These bug fix patches are mainly independent, even without my other
patches, they may be triggered theoretically.
Of course, these bug fix patches may need to ahead before the other PATCH,
otherwise the probability of the problems they fixed may be amplified in
an intermediate version.
What do you think?
Best Wishes.
D. Wythe
next prev parent reply other threads:[~2022-11-24 5:55 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-23 15:54 [PATCH net-next v5 00/10] optimize the parallelism of SMC-R connections D.Wythe
2022-11-23 15:54 ` [PATCH net-next v5 01/10] net/smc: fix potential panic dues to unprotected smc_llc_srv_add_link() D.Wythe
2022-11-23 15:54 ` [PATCH net-next v5 02/10] net/smc: fix application data exception D.Wythe
2022-11-23 15:54 ` [PATCH net-next v5 03/10] net/smc: fix SMC_CLC_DECL_ERR_REGRMB without smc_server_lgr_pending D.Wythe
2022-11-24 2:44 ` D. Wythe
2022-11-23 15:54 ` [PATCH net-next v5 04/10] net/smc: remove locks smc_client_lgr_pending and smc_server_lgr_pending D.Wythe
2022-11-23 15:54 ` [PATCH net-next v5 05/10] net/smc: allow confirm/delete rkey response deliver multiplex D.Wythe
2022-11-23 15:54 ` [PATCH net-next v5 06/10] net/smc: make SMC_LLC_FLOW_RKEY run concurrently D.Wythe
2022-11-23 15:54 ` [PATCH net-next v5 07/10] net/smc: llc_conf_mutex refactor, replace it with rw_semaphore D.Wythe
2022-11-23 15:54 ` [PATCH net-next v5 08/10] net/smc: use read semaphores to reduce unnecessary blocking in smc_buf_create() & smcr_buf_unuse() D.Wythe
2022-11-23 15:54 ` [PATCH net-next v5 09/10] net/smc: reduce unnecessary blocking in smcr_lgr_reg_rmbs() D.Wythe
2022-11-23 15:54 ` [PATCH net-next v5 10/10] net/smc: replace mutex rmbs_lock and sndbufs_lock with rw_semaphore D.Wythe
2022-11-24 5:55 ` D. Wythe [this message]
2022-11-24 8:33 ` [PATCH net-next v5 00/10] optimize the parallelism of SMC-R connections Jan Karcher
2022-11-24 8:53 ` D. Wythe
2022-11-24 13:30 ` Jan Karcher
2022-11-24 19:07 ` D. Wythe
2022-11-24 19:53 ` D. Wythe
2022-11-25 6:54 ` Jan Karcher
2022-11-26 9:08 ` D. Wythe
2022-11-28 11:46 ` Jan Karcher
2022-11-24 8:35 ` Jan Karcher
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=c98a8f04-c696-c9e0-4d7e-bc31109a0e04@linux.alibaba.com \
--to=alibuda@linux.alibaba.com \
--cc=davem@davemloft.net \
--cc=jaka@linux.ibm.com \
--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 \
--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