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
