[openib-general] [PATCH] IB/SRP: Enable multichannel
Lakshmanan, Madhu
mlakshmanan at silverstorm.com
Thu Sep 28 05:36:50 PDT 2006
>> 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
openib-general at openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit
http://openib.org/mailman/listinfo/openib-general
More information about the general
mailing list