All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wenjia Zhang <wenjia@linux.ibm.com>
To: "D. Wythe" <alibuda@linux.alibaba.com>,
	jaka@linux.ibm.com, kgraul@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 v6 1/7] net/smc: remove locks smc_client_lgr_pending and smc_server_lgr_pending
Date: Mon, 30 Jan 2023 22:10:46 +0100	[thread overview]
Message-ID: <bb50c952-6075-d838-0bc3-4848c12ad920@linux.ibm.com> (raw)
In-Reply-To: <a0de12ab-dd9a-acfe-4324-78815d6ebc35@linux.alibaba.com>



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@linux.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.
Sure, you can send the next version, I'll find a way to verify it.



> 
> 
> 

  reply	other threads:[~2023-01-30 21:12 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-26  9:03 [PATCH net-next v6 0/7] optimize the parallelism of SMC-R connections D.Wythe
2022-11-26  9:03 ` [PATCH net-next v6 1/7] net/smc: remove locks smc_client_lgr_pending and smc_server_lgr_pending D.Wythe
2023-01-29 15:11   ` D. Wythe
2023-01-30  8:37     ` Wenjia Zhang
2023-01-30 10:51       ` D. Wythe
2023-01-30 21:10         ` Wenjia Zhang [this message]
2023-01-31  3:06           ` D. Wythe
2022-11-26  9:03 ` [PATCH net-next v6 2/7] net/smc: allow confirm/delete rkey response deliver multiplex D.Wythe
2022-11-26  9:03 ` [PATCH net-next v6 3/7] net/smc: make SMC_LLC_FLOW_RKEY run concurrently D.Wythe
2022-11-26  9:03 ` [PATCH net-next v6 4/7] net/smc: llc_conf_mutex refactor, replace it with rw_semaphore D.Wythe
2022-11-26  9:03 ` [PATCH net-next v6 5/7] net/smc: use read semaphores to reduce unnecessary blocking in smc_buf_create() & smcr_buf_unuse() D.Wythe
2022-11-26  9:03 ` [PATCH net-next v6 6/7] net/smc: reduce unnecessary blocking in smcr_lgr_reg_rmbs() D.Wythe
2022-11-26  9:03 ` [PATCH net-next v6 7/7] net/smc: replace mutex rmbs_lock and sndbufs_lock with rw_semaphore D.Wythe

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=bb50c952-6075-d838-0bc3-4848c12ad920@linux.ibm.com \
    --to=wenjia@linux.ibm.com \
    --cc=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 \
    /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.