Re: iSCSI: current UNH Plugfest

[Santosh Rao <santoshr@cup.hp.com>]

I agree with Dave. I think a wire protocol is stepping out of bounds in
imposing this kind of restrictions on implementations. As long as an end
to end ordering scheme exists and is mandatory to implement/use, I don't
see why ordering within the initiator stack must be mandated ?

- Santosh

Dave Sheehy wrote:
> 
> > 3. Can commands be sent out of order on the same connection?
> >
> >    The behavior of targets is clearly specified in Section 2.2.2.3 on
> >    page 25 of draft 8, which says:
> >      "Except for the commands marked for immediate delivery the iSCSI
> >      target layer MUST eliver the commands for execution in the order
> >      specified by CmdSN."
> >
> >    Section 2.2.2.3 on page 26 of draft 8 also says:
> >      "- CmdSN - the current command Sequence Number advanced by 1 on
> >      each command shipped except for commands marked for immediate
> >      delivery."
> >    but the meaning of the term "shipped" is vague, and does not
> > necessarily
> >    require that the PDUs arrive on the other end of a TCP connection
> >    in the same order that the CmdSN values were assigned to these PDUs.
> >
> >    Some initiators have been designed to send commands out of CmdSN
> >    order on one connection.  Consider the situation where there is only
> >    one connection and a high-level dispatcher creates a PDU for a SCSI
> >    command that involves writing immediate data to the target.  This PDU
> >    is enqueued to a lower-level layer which has to setup, start, and
> >    wait-for a DMA operation to move the immediate data into an onboard
> >    buffer before the PDU can be put onto the wire.  While this is
> >    happening, the dispatcher creates another unrelated PDU for a SCSI
> >    read command (for example), and when this PDU is passed to the
> >    lower-level layer it can be sent immediately, ahead of the previous
> >    write PDU and therefore out of order on this connection.
> >
> >    The standard clearly allows this to happen if the two PDUs were sent
> >    on different connections, and seems to imply that this can also happen
> >    when the two PDUs are sent on the same connection.
> >
> >    The suggestion is to put in the standard an explicit statement that
> >    this is allowed or not allowed, as appropriate.
> >
> >    If this is allowed, such a statement would avoid the erroneous
> >    assumption being made by some target implementers that within a single
> >    connection, commands will arrive in order.
> >
> >    If this is not allowed, such a statement would avoid the erroneous
> >    assumption being made by some initiator implementers that within a
> >    single connection, commands can be put on the wire out of order.
> >
> > +++
> >
> > will add an explicit statement saying that this behaviour is forbidden.
> > 2.2.2.1 will contain:
> >
> > On any given connection, the iSCSI initiator MUST send the commands in the
> > order specified by CmdSN.
> >
> > +++
> 
> Why do you feel this behavior should be forbidden? Targets already have to
> order commands across the session. I don't see why it's a problem to extend
> that to the connection as well. I, for one, believe we should take a liberal
> stance on this.
> 
> Dave Sheehy

-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
##################################