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@xxxxxxxxxxxxxxxxx>
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
