[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9af1f859-0299-d1d7-d5ce-af46cf102025@linux.ibm.com>
Date: Wed, 17 Nov 2021 17:19:18 +0100
From: Karsten Graul <kgraul@...ux.ibm.com>
To: Tony Lu <tonylu@...ux.alibaba.com>
Cc: kuba@...nel.org, davem@...emloft.net, guwen@...ux.alibaba.com,
netdev@...r.kernel.org, linux-s390@...r.kernel.org,
linux-rdma@...r.kernel.org
Subject: Re: [PATCH RFC net] net/smc: Ensure the active closing peer first
closes clcsock
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.
Powered by blists - more mailing lists