From: Karsten Graul <kgraul@linux.ibm.com>
To: Tony Lu <tonylu@linux.alibaba.com>
Cc: kuba@kernel.org, davem@davemloft.net, guwen@linux.alibaba.com,
netdev@vger.kernel.org, linux-s390@vger.kernel.org,
linux-rdma@vger.kernel.org
Subject: Re: [PATCH RFC net] net/smc: Ensure the active closing peer first closes clcsock
Date: Wed, 17 Nov 2021 17:19:18 +0100 [thread overview]
Message-ID: <9af1f859-0299-d1d7-d5ce-af46cf102025@linux.ibm.com> (raw)
In-Reply-To: <20211116033011.16658-1-tonylu@linux.alibaba.com>
On 16/11/2021 04:30, Tony Lu wrote:
> We found an issue when replacing TCP with SMC. When the actively closed
> peer called close() in userspace, the clcsock of peer doesn't enter TCP
> active close progress, but the passive closed peer close it first, and
> enters TIME_WAIT state. It means the behavior doesn't match what we
> expected. After reading RFC7609, there is no clear description of the
> order in which we close clcsock during close progress.
Thanks for your detailed description, it helped me to understand the problem.
Your point is that SMC sockets should show the same behavior as TCP sockets
in this situation: the side that actively closed the socket should get into
TIME_WAIT state, and not the passive side. I agree with this.
Your idea to fix it looks like a good solution for me. But I need to do more
testing to make sure that other SMC implementations (not Linux) work as
expected with this change. For example, Linux does not actively monitor the
clcsocket state, but if another implementation would do this it could happen
that the SMC socket is closed already when the clcsocket shutdown arrives, and
pending data transfers are aborted.
I will respond to your RFC when I finished my testing.
Thank you.
next prev parent reply other threads:[~2021-11-17 16:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-16 3:30 [PATCH RFC net] net/smc: Ensure the active closing peer first closes clcsock Tony Lu
2021-11-17 16:19 ` Karsten Graul [this message]
2021-11-22 16:47 ` Karsten Graul
2021-11-23 3:03 ` Tony Lu
2021-11-23 9:26 ` Karsten Graul
2021-11-24 8:57 ` Tony Lu
2021-11-24 10:08 ` Karsten Graul
2021-11-24 11:26 ` Tony Lu
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=9af1f859-0299-d1d7-d5ce-af46cf102025@linux.ibm.com \
--to=kgraul@linux.ibm.com \
--cc=davem@davemloft.net \
--cc=guwen@linux.alibaba.com \
--cc=kuba@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--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 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.