Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <5a678df91455e29f296de25ef4aee25cae0e23d6.camel@linux.ibm.com>
Subject: Re: [RFC PATCH net-next v4 0/9] net/smc: Introduce SMC-D-based OS
 internal communication acceleration
From:   Niklas Schnelle <schnelle@linux.ibm.com>
To:     Alexandra Winter <wintera@linux.ibm.com>,
        Wen Gu <guwen@linux.alibaba.com>, kgraul@linux.ibm.com,
        wenjia@linux.ibm.com, jaka@linux.ibm.com, davem@davemloft.net,
        edumazet@google.com, kuba@kernel.org, pabeni@redhat.com
Cc:     linux-s390@vger.kernel.org, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Date:   Thu, 06 Apr 2023 16:27:29 +0200
In-Reply-To: <33ab688e-88c9-d950-be66-f0f79774ff6c@linux.ibm.com>
References: <1679887699-54797-1-git-send-email-guwen@linux.alibaba.com>
         <6156aaad710bc7350cbae6cb821289c8a37f44bb.camel@linux.ibm.com>
         <33ab688e-88c9-d950-be66-f0f79774ff6c@linux.ibm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) 
MIME-Version: 1.0
Precedence: bulk

On Thu, 2023-04-06 at 13:14 +0200, Alexandra Winter wrote:
>=20
> On 05.04.23 19:04, Niklas Schnelle wrote:
> > One more question though, what about the SEID why does that have to be
> > fixed and at least partially match what ISM devices use? I think I'm
> > missing some SMC protocol/design detail here. I'm guessing this would
> > require a protocol change?
> >=20
> > Thanks,
> > Niklas
>=20
> Niklas,
> in the initial SMC CLC handshake the client and server exchange the SEID =
(one per peer system)
> and up to 8 proposals for SMC-D interfaces.
> Wen's current proposal assumes that smc-d loopback can be one of these 8 =
proposed interfaces,
> iiuc. So on s390 the proposal can contain ISM devices and a smc-d loopbac=
k device at the same time.
> If one of the peers is e.g. an older Linux version, it will just ignore t=
he loopback-device
> in the list (Don't find a match for CHID 0xFFFF) and use an ISM interface=
 for SMC-D if possible.
> Therefor it is important that the SEID is used in the same way as it is t=
oday in the handshake.
>=20
> If we decide for some reason (virtio-ism open issues?) that a protocol ch=
ange/extension is
> required/wanted, then it is a new game and we can come up with new identi=
fiers, but we may
> lose compatibility to backlevel systems.
>=20
> Alexandra

Ok that makes sense to me. I was looking at the code in patch 4 of this
series and there it looks to me like SMC-D loopback as implemented
would always use the newly added SMCD_DEFAULT_V2_SEID might have
misread it though. From your description I think that would be wrong,
if a SEID is defined as on s390 it should use that SEID in the CLC for
all SMC variants. Similarly on other architectures it should use the
same SEID for SMC-D as for SMC-R, right? Also with partially match I
was actually wrong the SMCD_DEFAULT_V2_SEID.seid_string starts with
"IBM-DEF-ISMSEID=E2=80=A6" while on s390's existing ISM we use "IBM-SYSZ-
ISMSEID=E2=80=A6" so if SMC-D loopback correctly uses the shared SEID on s3=
90
we can already only get GID.DMB collisions only on the same mainframe.

Thanks,
Niklas