public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Wen Gu <guwen@linux.alibaba.com>
To: Alexandra Winter <wintera@linux.ibm.com>,
	Jan Karcher <jaka@linux.ibm.com>,
	kgraul@linux.ibm.com, wenjia@linux.ibm.com, davem@davemloft.net,
	edumazet@google.com, kuba@kernel.org, pabeni@redhat.com
Cc: schnelle@linux.ibm.com, gbayer@linux.ibm.com,
	pasic@linux.ibm.com, alibuda@linux.alibaba.com,
	tonylu@linux.alibaba.com, dust.li@linux.alibaba.com,
	linux-s390@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v4 05/18] net/smc: reserve CHID range for SMC-D virtual device
Date: Wed, 4 Oct 2023 16:27:11 +0800	[thread overview]
Message-ID: <bcb4f377-715a-e7c3-8798-0c766be11201@linux.alibaba.com> (raw)
In-Reply-To: <987f4ee8-57ab-71c2-597d-7835c3e1e202@linux.ibm.com>



On 2023/9/28 17:10, Alexandra Winter wrote:
> 
> 
> On 28.09.23 05:08, Jan Karcher wrote:
>> On 24/09/2023 17:16, Wen Gu wrote:
>>> This patch reserve CHID range from 0xFF00 to 0xFFFF for SMC-D virtual
>>
>> The current state is that 0xFF00 - 0xFFFF is the range of all virtual SMC-D devices. This range devides into:
>> - 0xFF00 - 0xFFFE is for virto-ism
>> - 0xFFFF is for loopback
>>
>>
>>> device and introduces helpers to identify them.
>>>
>>> Signed-off-by: Wen Gu <guwen@linux.alibaba.com>
>>> ---
>>>    net/smc/smc_ism.h | 15 +++++++++++++++
>>>    1 file changed, 15 insertions(+)
>>>
>>> diff --git a/net/smc/smc_ism.h b/net/smc/smc_ism.h
>>> index 14d2e77..2ecc8de 100644
>>> --- a/net/smc/smc_ism.h
>>> +++ b/net/smc/smc_ism.h
>>> @@ -15,6 +15,9 @@
>>>      #include "smc.h"
>>>    +#define SMC_VIRT_ISM_CHID_MAX        0xFFFF
>>
>> SMC_VIRT_ISM_MAX is 0xFFFE. Or do you mean virtual devices as the whole group. If yes i think that this naming will be very confusing in a few months/years.
>> Maybe something like SMC_VIRTUAL_DEV_CHID_{MIN|MAX}?
> 
> 
> IMO names are important. They can make future lives easier or harder.
> 


Hi Sandy and Jan,

I agree with your opinion that names are important.

I view these terms in this way:

SMC-D devices (smcd_dev)
    |
    |- s390 ISM devices (ISM, ism_dev)
    |
    |- virtual ISM devices (virtual ISM, smc_lo_dev)
    |     |
    |     |- loopback-ism
    |     |
    |     |- virtio-ism
    |
    |- maybe future devices

SMC_VIRT_ISM_CHID_MAX was introduced to represent the maximum CHID of virtual ISM devices. CHIDs used
by virtual ISM devices should be in range of [SMC_VIRT_ISM_CHID_MIN, SMC_VIRT_ISM_CHID_MAX].

I think the problem here is that SMC_VIRT_ISM_CHID_MAX might be misunderstood as CHID of virtio-ism?
Then I will change them to SMC_VIRTUAL_ISM_CHID_{MAX|MIN}.

> Your first group of patches aims at 'decouple ISM device hard code from SMC-D stack'
> Maybe now would be a good point in time to decide what ISM should mean in net/smc.
> a) the s390 ISM devices
> b) SMC-D devices in general
> I would vote for a). (today a) and b) can be found in the code, as well as the term smcd_dev)
> 
> Then like Jan wrote above:
> "0xFF00 - 0xFFFF is the range of all virtual SMC-D devices" and it should NOT be called SMC_VIRT_ISM_CHID_MAX.
> 

Yes, I also vote for a).

But IMHO, loopback-ism and virtio-ism should be better classified as 'virtual ISM devices', like
what describes in the specification, rather than 'virtual SMC-D devices', since they are intended
to emulate ISM devices for using SMC-D on non-s390 systems.

> 
> Then in many places in net/smc 'ism' should be replaces by 'smcd_dev' or something similar.
> Wen Gu, is that something you would offer to do as part of the preparation work for this series?

Yes. But I'm not sure which 'ism' words you suggested to be replaced with 'smcd_dev'/'smcd'?

IMHO, in some generic codes like SMC-D operations (smcd_ops) or SMC-D device dump, they should
be generic to all kinds of SMC-D devices, so struct ism_dev or struct ism_client should not be used,
that is what patch#1 & #2 want to do.

But in some operations related to underlay device, like smcd_ism_register_dmb(), smc_ism_cantalk(),
and etc in smc_ism.c. They works for both s390 ISM devices and virtual ISM devices. I think they can
keep 'ism' in the helpers' name as they are now.

What do you think?

Thanks and regards,
Wen Gu





  reply	other threads:[~2023-10-04  8:27 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-24 15:16 [PATCH net-next v4 00/18] net/smc: implement virtual ISM extension and loopback-ism Wen Gu
2023-09-24 15:16 ` [PATCH net-next v4 01/18] net/smc: decouple ism_dev from SMC-D device dump Wen Gu
2023-09-24 15:16 ` [PATCH net-next v4 02/18] net/smc: decouple ism_dev from SMC-D DMB registration Wen Gu
2023-09-24 15:16 ` [PATCH net-next v4 03/18] net/smc: extract v2 check helper from SMC-D device registration Wen Gu
2023-09-28  3:08   ` Jan Karcher
2023-09-30  8:41     ` Wen Gu
2023-09-24 15:16 ` [PATCH net-next v4 04/18] net/smc: support SMCv2.x supplemental features negotiation Wen Gu
2023-09-24 15:16 ` [PATCH net-next v4 05/18] net/smc: reserve CHID range for SMC-D virtual device Wen Gu
2023-09-28  3:08   ` Jan Karcher
2023-09-28  9:10     ` Alexandra Winter
2023-10-04  8:27       ` Wen Gu [this message]
2023-09-24 15:16 ` [PATCH net-next v4 06/18] net/smc: extend GID to 128bits only for virtual ISM device Wen Gu
2023-10-12  7:54   ` Dust Li
2023-10-12 13:24     ` Wen Gu
2023-09-24 15:16 ` [PATCH net-next v4 07/18] net/smc: disable SEID on non-s390 architecture Wen Gu
2023-09-24 15:16 ` [PATCH net-next v4 08/18] net/smc: enable virtual ISM device feature bit Wen Gu
2023-09-24 15:16 ` [PATCH net-next v4 09/18] net/smc: introduce SMC-D loopback device Wen Gu
2023-09-25 11:50   ` Alexandra Winter
2023-09-25 13:29     ` Alexandra Winter
2023-09-25 14:20       ` Wen Gu
2023-09-25 13:57     ` Wen Gu
2023-09-25 15:18     ` Dust Li
2023-09-26  7:24       ` Alexandra Winter
2023-09-28  3:16         ` Jan Karcher
2023-09-28 18:35           ` Wen Gu
2023-09-29 14:08             ` Alexandra Winter
2023-10-04  9:05               ` Wen Gu
2023-09-24 15:16 ` [PATCH net-next v4 10/18] net/smc: implement ID-related operations of loopback Wen Gu
2023-10-18 13:24   ` Alexandra Winter
2023-09-24 15:16 ` [PATCH net-next v4 11/18] net/smc: implement some unsupported " Wen Gu
2023-09-24 15:16 ` [PATCH net-next v4 12/18] net/smc: implement DMB-related " Wen Gu
2023-09-24 23:29   ` kernel test robot
2023-09-25  1:47     ` Wen Gu
2023-09-24 15:16 ` [PATCH net-next v4 13/18] net/smc: register loopback device as SMC-Dv2 device Wen Gu
2023-09-24 15:16 ` [PATCH net-next v4 14/18] net/smc: add operation for getting DMB attribute Wen Gu
2023-09-24 15:16 ` [PATCH net-next v4 15/18] net/smc: add operations for DMB attach and detach Wen Gu
2023-09-24 15:16 ` [PATCH net-next v4 16/18] net/smc: avoid data copy from sndbuf to peer RMB in SMC-D Wen Gu
2023-09-24 15:16 ` [PATCH net-next v4 17/18] net/smc: modify cursor update logic when sndbuf mapped to RMB Wen Gu
2023-09-24 15:16 ` [PATCH net-next v4 18/18] net/smc: add interface implementation of loopback device Wen Gu
2023-09-26  7:30 ` [PATCH net-next v4 00/18] net/smc: implement virtual ISM extension and loopback-ism Alexandra Winter
2023-09-27 15:16 ` Alexandra Winter
2023-09-28  8:56   ` Alexandra Winter
2023-09-28 17:29     ` Wen Gu
2023-09-29 13:31       ` Alexandra Winter
2023-10-04  8:42         ` Wen Gu
2023-09-28 16:42   ` Wen Gu
2023-10-05  8:21 ` Niklas Schnelle
2023-10-08  7:19   ` Wen Gu
2023-10-17  3:49     ` Wen Gu
2023-10-18 19:43       ` Wenjia Zhang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bcb4f377-715a-e7c3-8798-0c766be11201@linux.alibaba.com \
    --to=guwen@linux.alibaba.com \
    --cc=alibuda@linux.alibaba.com \
    --cc=davem@davemloft.net \
    --cc=dust.li@linux.alibaba.com \
    --cc=edumazet@google.com \
    --cc=gbayer@linux.ibm.com \
    --cc=jaka@linux.ibm.com \
    --cc=kgraul@linux.ibm.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pasic@linux.ibm.com \
    --cc=schnelle@linux.ibm.com \
    --cc=tonylu@linux.alibaba.com \
    --cc=wenjia@linux.ibm.com \
    --cc=wintera@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox