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

[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@xxxxxxxxxxxxx/
> [2] 
> https://lore.kernel.org/netdev/60b4aec0b4bf4474d651b653c86c280dafc4518a.camel@xxxxxxxxxxxxx/

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