Re: [RFC PATCH net-next v4 0/9] net/smc: Introduce SMC-D-based OS internal communication acceleration

[Niklas Schnelle]

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