Re: [RFC PATCH net-next v5 00/11] net/smc: SMC intra-OS shortcut with loopback-ism

[Wenjia Zhang <wenjia@linux.ibm.com>]

On 11.04.24 09:45, Wen Gu wrote:
> 
> 
> On 2024/4/3 19:10, Gerd Bayer wrote:
>> On Wed, 2024-04-03 at 14:35 +0800, Wen Gu wrote:
>>>
>>>
>>> On 2024/3/24 21:55, Wen Gu wrote:
>>>> This patch set acts as the second part of the new version of [1]
>>>> (The first
>>>> part can be referred from [2]), the updated things of this version
>>>> are listed
>>>> at the end.
>>>
>>>> Change log:
>>>>
>>>> RFC v5->RFC v4:
>>>> - Patch #2: minor changes in description of config SMC_LO and
>>>> comments.
>>>> - Patch #10: minor changes in comments and
>>>> if(smc_ism_support_dmb_nocopy())
>>>>     check in smcd_cdc_msg_send().
>>>> - Patch #3: change smc_lo_generate_id() to smc_lo_generate_ids()
>>>> and SMC_LO_CHID
>>>>     to SMC_LO_RESERVED_CHID.
>>>> - Patch #5: memcpy while holding the ldev->dmb_ht_lock.
>>>> - Some expression changes in commit logs.
>>>>
>>>
>>> Hi, Jan. Do you have any comments on this version and should I post a
>>> new patch series without 'RFC'? Thank you.
>>
>> Hi Wen,
>>
>> Jan has been out sick for a little while now, and Wenjia is expected
>> back from a longer vacation tomorrow. So if you could hold off until
>> begin of next week, Wenjia might have some more feedback.
>>
>> In the meantime, I'm looking at your patchset...
>>
>> Thank you, Gerd
>>
> 
> Hi Gerd, is there any further information? I am wondering if I
> should wait for more feedback from SMC maintainers. Thanks!
> 
> 
> Hi Wenjia, when it's convenient for you, could you please confirm
> if [1] and [2] need to be included in the next version? Thanks!
> 
> [1] 
> https://lore.kernel.org/netdev/7291dd1b2d16fd9bbd90988ac5bcc3a46d17e3f4.camel@linux.ibm.com/
> [2] 
> https://lore.kernel.org/netdev/60b4aec0b4bf4474d651b653c86c280dafc4518a.camel@linux.ibm.com/
> 

Hi Wen,

I'm just back, thank you for the patience!

Firstly I want to thank Gerd and Niklas for review and bringing up these 
points!

Here are some of my options on that:

To [1]:
I agree to document the ops as otional if it must not be supported. 
Since I don't really have any ideas, the classification souds reasonable 
to me. Going to the details, what about to take following options as 
mandatory:

* query_remote_gid()
* register_dmb()/unregister_dmb()
* move_data() : I do see the necessary here.
* get_local_gid()
* get_chid()
* get_dev()

To [2]:
I also agree to keep the ism-loopback at the very beginning of the List. 
That acting is also what I imaged previously. Thank you, gerd, again for 
testing it and find it out!

Thanks,
Wenjia