Messages in this thread | | | Date | Thu, 11 Apr 2024 11:32:58 +0200 | Subject | Re: [RFC PATCH net-next v5 00/11] net/smc: SMC intra-OS shortcut with loopback-ism | From | Wenjia Zhang <> |
| |
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
| |