[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <edb7dc54-a7f9-4356-a2a4-905b5f48b1f0@linux.ibm.com>
Date: Tue, 5 Dec 2023 10:51:28 +0100
From: Alexandra Winter <wintera@...ux.ibm.com>
To: Wen Gu <guwen@...ux.alibaba.com>, wenjia@...ux.ibm.com, hca@...ux.ibm.com,
gor@...ux.ibm.com, agordeev@...ux.ibm.com, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
kgraul@...ux.ibm.com, jaka@...ux.ibm.com
Cc: borntraeger@...ux.ibm.com, svens@...ux.ibm.com, alibuda@...ux.alibaba.com,
tonylu@...ux.alibaba.com, raspl@...ux.ibm.com, schnelle@...ux.ibm.com,
linux-s390@...r.kernel.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v3 5/7] net/smc: compatible with 128-bits extend
GID of virtual ISM device
On 04.12.23 13:24, Wen Gu wrote:
> Thank you very much for review. See below.
>
> On 2023/12/2 00:30, Alexandra Winter wrote:
>>
>>
>> On 30.11.23 12:28, Wen Gu wrote:
>> [...]
>>> diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
>>> index 766a1f1..d1e18bf 100644
>>> --- a/net/smc/af_smc.c
>>> +++ b/net/smc/af_smc.c
>> [...]
>>> @@ -1048,7 +1048,8 @@ static int smc_find_ism_v2_device_clnt(struct smc_sock *smc,
>>> {
>>> int rc = SMC_CLC_DECL_NOSMCDDEV;
>>> struct smcd_dev *smcd;
>>> - int i = 1;
>>> + int i = 1, entry = 1;
>>> + bool is_virtual;
>>> u16 chid;
>>> if (smcd_indicated(ini->smc_type_v1))
>>> @@ -1060,14 +1061,23 @@ static int smc_find_ism_v2_device_clnt(struct smc_sock *smc,
>>> chid = smc_ism_get_chid(smcd);
>>> if (!smc_find_ism_v2_is_unique_chid(chid, ini, i))
>>> continue;
>>> + is_virtual = __smc_ism_is_virtual(chid);
>>> if (!smc_pnet_is_pnetid_set(smcd->pnetid) ||
>>> smc_pnet_is_ndev_pnetid(sock_net(&smc->sk), smcd->pnetid)) {
>>> + if (is_virtual && entry == SMC_MAX_ISM_DEVS)
>>> + /* only one GID-CHID entry left in CLC Proposal SMC-Dv2
>>> + * extension. but a virtual ISM device's GID takes two
>>> + * entries. So give up it and try the next potential ISM
>>> + * device.
>>> + */
>>
>> It is really importatnt to note that virtual ISMs take 2 entries.
>> But it is still hard to understand this piece of code. e.g. I was wondering for a while,
>> why you mention CLC here...
>> Maybe it would be easier to understand this, if you rename SMC_MAX_ISM_DEVS to something else?
>> Something like SMCD_MAX_V2_GID_ENTRIES?
>>
>
> I agree.
>
> But I perfer to define a new macro to represent the max ISMv2 entries in CLC proposal message,
> e.g. SMCD_CLC_MAX_V2_GID_ENTRIES, and keep using SMC_MAX_ISM_DEVS to represent the max devices
> that can be proposed. Both semantics are required in the code, such as:
>
> ini->ism_dev[SMC_MAX_ISM_DEVS] | smcd_v2_ext->gidchid[SMCD_CLC_MAX_V2_GID_ENTRIES]
> -------------------------------------------------------------------------------------------
> [1:virtual_ISM_1] | [1:virtual_ISM_1 GID]
> | [2:virtual_ISM_1 extension GID]
> [2:ISM_2] | [3:ISM_2 GID/CHID]
> [3:ISM_3] | [4:ISM_3 GID/CHID]
>
> And SMC_MAX_ISM_DEVS is required no more than SMCD_CLC_MAX_V2_GID_ENTRIES.
I agree, this is even better.
Powered by blists - more mailing lists