>> Roland Dreier wrote: >> Maybe we should just use the port GUID instead of the node GUID to >> form the initiator ID? That would solve this pretty cleanly I think.
> This is also Vu's idea. > > There are two issues: > > 1) My patch allows a sophisticated user to have two logical connections on > the same physical solution. He can have different connection parameters > (e.g., MAX_CMD_PER_LUN) according to the application needs. > Do you think there is such need? > > 2) In the current implementation there is a problem when there are two > connections on the same physical connection - when the second connection > sends REQ to the target, the target sends a DREQ to the first connection, > but when someone tries to access the first scsi_host, ib_srp tries to > reconnect the first connection and then the second connection gets a DREQ > - and so the ping pong goes. > And if there is a multipath daemon that checks the status of the > connections this ping pong can be for ever. > We need to find a way to eliminate this behavior. > Ishai Silverstorm's native SRP implementation allows for the initiator ID to be the port GUID and the initiator extension to be user-specified. This approach is taken to initiate multiple connections to a single SRP target from the same host; i.e. the initiator ID is kept the same (port GUID) and a different initiator extension is specified. Btw, could you point me to the latest source code? I didn't see it under gen2/trunk/src/linux-kernel/infiniband/ulp/srp. I'd like to collaborate with you on OFED SRP. Madhu Lakshmanan SilverStorm Technologies _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
