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
Subject: Re: [RFC PATCH net-next v4 0/9] net/smc: Introduce SMC-D-based OS internal communication acceleration
Date: Thu, 06 Apr 2023 16:27:29 +0200 [thread overview]
Message-ID: <5a678df91455e29f296de25ef4aee25cae0e23d6.camel@linux.ibm.com> (raw)
In-Reply-To: <33ab688e-88c9-d950-be66-f0f79774ff6c@linux.ibm.com>
On Thu, 2023-04-06 at 13:14 +0200, Alexandra Winter wrote:
>
> 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?
> >
> > Thanks,
> > Niklas
>
> 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 loopback device at the same time.
> If one of the peers is e.g. an older Linux version, it will just ignore the 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 today in the handshake.
>
> If we decide for some reason (virtio-ism open issues?) that a protocol change/extension is
> required/wanted, then it is a new game and we can come up with new identifiers, but we may
> lose compatibility to backlevel systems.
>
> 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…" while on s390's existing ISM we use "IBM-SYSZ-
ISMSEID…" so if SMC-D loopback correctly uses the shared SEID on s390
we can already only get GID.DMB collisions only on the same mainframe.
Thanks,
Niklas
next prev parent reply other threads:[~2023-04-06 14:27 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-27 3:28 [RFC PATCH net-next v4 0/9] net/smc: Introduce SMC-D-based OS internal communication acceleration Wen Gu
2023-03-27 3:28 ` [RFC PATCH net-next v4 1/9] net/smc: Decouple ism_dev from SMC-D device dump Wen Gu
2023-03-27 3:28 ` [RFC PATCH net-next v4 2/9] net/smc: Decouple ism_dev from SMC-D DMB registration Wen Gu
2023-03-27 3:28 ` [RFC PATCH net-next v4 3/9] net/smc: Extract v2 check helper from SMC-D device registration Wen Gu
2023-03-27 3:28 ` [RFC PATCH net-next v4 4/9] net/smc: Introduce SMC-D loopback device Wen Gu
2023-03-27 3:28 ` [RFC PATCH net-next v4 5/9] net/smc: Introduce an interface for getting DMB attribute Wen Gu
2023-03-27 3:28 ` [RFC PATCH net-next v4 6/9] net/smc: Introudce interfaces for DMB attach and detach Wen Gu
2023-03-27 3:28 ` [RFC PATCH net-next v4 7/9] net/smc: Avoid data copy from sndbuf to peer RMB in SMC-D Wen Gu
2023-03-27 3:28 ` [RFC PATCH net-next v4 8/9] net/smc: Modify cursor update logic when using mappable DMB Wen Gu
2023-03-27 3:28 ` [RFC PATCH net-next v4 9/9] net/smc: Add interface implementation of loopback device Wen Gu
2023-04-05 14:48 ` [RFC PATCH net-next v4 0/9] net/smc: Introduce SMC-D-based OS internal communication acceleration Wenjia Zhang
2023-04-10 14:31 ` Wen Gu
2023-04-05 17:04 ` Niklas Schnelle
2023-04-06 11:14 ` Alexandra Winter
2023-04-06 14:27 ` Niklas Schnelle [this message]
2023-04-10 14:30 ` Wen Gu
2023-04-10 14:30 ` Wen Gu
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=5a678df91455e29f296de25ef4aee25cae0e23d6.camel@linux.ibm.com \
--to=schnelle@linux.ibm.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=guwen@linux.alibaba.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=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