Message-ID: <82545b5f-2b9e-61ab-9e67-866e2a492904@linux.alibaba.com>
Date:   Tue, 31 Jan 2023 11:06:07 +0800
From:   "D. Wythe" <alibuda@...ux.alibaba.com>
To:     Wenjia Zhang <wenjia@...ux.ibm.com>, jaka@...ux.ibm.com,
        kgraul@...ux.ibm.com
Cc:     kuba@...nel.org, davem@...emloft.net, netdev@...r.kernel.org,
        linux-s390@...r.kernel.org, linux-rdma@...r.kernel.org
Subject: Re: [PATCH net-next v6 1/7] net/smc: remove locks
 smc_client_lgr_pending and smc_server_lgr_pending



On 1/31/23 5:10 AM, Wenjia Zhang wrote:
> 
> 
> On 30.01.23 11:51, D. Wythe wrote:
>>
>>
>> On 1/30/23 4:37 PM, Wenjia Zhang wrote:
>>>
>>>
>>> On 29.01.23 16:11, D. Wythe wrote:
>>>>
>>>>
>>>> On 11/26/22 5:03 PM, D.Wythe wrote:
>>>>> From: "D. Wythe" <alibuda@...ux.alibaba.com>
>>>>>
>>>>> This patch attempts to remove locks named smc_client_lgr_pending and
>>>>> smc_server_lgr_pending, which aim to serialize the creation of link
>>>>> group. However, once link group existed already, those locks are
>>>>> meaningless, worse still, they make incoming connections have to be
>>>>> queued one after the other.
>>>>>
>>>>> Now, the creation of link group is no longer generated by competition,
>>>>> but allocated through following strategy.
>>>>>
>>>>
>>>>
>>>> Hi, all
>>>>
>>>> I have noticed that there may be some difficulties in the advancement of this series of patches.
>>>> I guess the main problem is to try remove the global lock in this patch, the risks of removing locks
>>>> do harm to SMC-D, at the same time, this patch of removing locks is also a little too complex.
>>>>
>>>> So, I am considering that we can temporarily delay the advancement of this patch. We can works on
>>>> other patches first. Other patches are either simple enough or have no obvious impact on SMC-D.
>>>>
>>>> What do you think?
>>>>
>>>> Best wishes.
>>>> D. Wythe
>>>>
>>>>
>>> Hi D. Wythe,
>>>
>>> that sounds good. Thank you for your consideration about SMC-D!
>>
>> Hi Wenjia,
>>
>> Thanks for your reply.
>>
>>> Removing locks is indeed a big issue, those patches make us difficult to accept without thoroughly testing in every corner.
>>>
>>> Best
>>> Wenjia
>>
>> What do you mean by those patches? My plan is to delete the first patch in this series,
>> that is, 'remove locks smc_client_lgr_pending and smc_server_lgr_pending', while other patches
>> should be retained.
>>
>> They has almost nothing impact on SMC-D or simple enough to be tested. If you agree with this,
>> I can then issue the next version as soon as possible to remove the first patch, and I think
>> we can quickly promote those patches.
>>
>> Thanks.
>> Wenjia
>>
> Except for the removing locks of smc_client_lgr_pending and smc_server_lgr_pending, I'm still not that sure if running SMC_LLC_FLOW_RKEY concurrently could make the communication between our Linux and z/OS broken, that we can not test currently, though I really like this idea.

Hi, Wenjia

This is really a situation that I hadn't considered before, and I'm afraid it can be a problem, if implementation of z/OS do need to process SMC_LLC_FLOW_RKEY
one by one, and i guess it's very possible.


> Sure, you can send the next version, I'll find a way to verify it.

Whatever, I will issue the next patches with first patch removed, and if we cannot pass the compatibility
test with z/OS, I think we have to give up the patch tried to running SMC_LLC_FLOW_RKEY concurrently.

Fortunately, we have discussed the possibility of protocol extension before. If the patch tried to running SMC_LLC_FLOW_RKEY concurrently
cannot be promoted temporarily, we can also promote it again after the protocol extension is completed.

Thanks.
D. Wythe
> 
> 
> 
>>
>>
>>

Powered by blists - more mailing lists