[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