comments on T10/01-150r0, Minutes of the SRP WG – Ma?==?iso-8859-1?Q?y 3, 2001 – Nashua, NH

Edward A. Gardner eag at
Thu May 10 14:12:45 PDT 2001

* From the T10 Reflector (t10 at, posted by:
* "Edward A. Gardner" <eag at>
>Cris Simpson will propose a Login Reject IU that can be carried as
>with the CM_REJ message.

I thought we already had this.  When I documented the logout IU (discussed
in Jan 4-5 and Feb 20-21 minutes), it seemed obvious that reasons for
terminating a channel and reasons for rejecting a channel were almost
identical.  I've described SRP_LOGOUT as being used for both purposes.  I
believe that was discussed in those meetings, but it doesn't appear in the
official minutes.

In any case, a simple way to report SRP layer reasons for rejecting channel
establishment is to carry an SRP_LOGOUT as the PrivateData in the CM_REJ
message.  Strictly speaking all you need is the reason code, but dressing it
up to look like a normal SRP IU may be of benefit some day.

>The group discussed whether a CM disconnect can destroy the queue pair
>the application has processed all outstanding IOs on that queue pair. If
>a Logout Acknowledge IU would be needed to ensure clean disconnections.
>Cris Simpson will research the issue.

I don't see how this is an issue.  A queue pair exists until the consumer
(i.e. the application) issues a Destroy Queue Pair verb (v1 page 375, 446
and 469).  How the CM tells the consumer that a connection has disappeared
is on of the "internal interfaces" that "are outside the scope of the
Infiniband Architecture" (v1 page 516).  But the CM can't delete queue pairs
or any other resources out from under the consumer with first synchronizing
with it.

>The group agreed that a note should be added to SRP indicating that linked
>commands are not supported.

What is the nature of this note?  Does anything similar exist in other
protocol specifications?

On a technical note, I am an enthusiastic supporter of removing linked
commands from SAM-n.  However I must also say that supporting linked
commands in SRP is quite trivial -- I don't see where we have to even say
anything.  If you want to use such abominations, they already work just as
described in SAM.

>Bill proposed combining SRP_CMD_16, SRP_CMD_32, and SRP_CMD_LONG back into
>a single SRP_CMD_IU. The target must accept the whole packet and check its
>CRC before parsing it, so there is no real advantage in fixed length
>The group recommended that 01-164r0 be incorporated into SRP by a vote of


>14 Review new action items

>Cris Simpson will research whether a Login Acknowledge IU is needed.
should be logout ---------------------^^^^^

>The SRP editor should incorporate 01-064r0.
I hope this should be 01-164 ------^^^^^^^^

Edward A. Gardner               eag at
Ophidian Designs                719 593-8866 voice
1262 Hofstead Terrace           719 593-8989 fax
Colorado Springs, CO  80907     719 210-7200 cell

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list