Subject: Re: [Ips] iSCSI cmd ordering and tagged task

From: [email-masked]
Date: Wed, 19 Nov 2003 09:50:28 -0500

Dan,

This is not really a limitation since iSCSI allows commands to be
processed, and status returned, in a different order than they were
received.  Multiple outstanding commands to the same lun are accepted as
long as they are within the command window (Max Command Sn - Expected
Command SN. )  iSCSI allows tagged commands to be reordered by the target
for efficiency's sake.   One could assume that the initiator is sending
them in order, so, again, any reordering that happens at the target device
side is legal.

I think that your confusion may arise from the idea that the initiator is
somehow reordering the commands at its iSCSI layer, which would require
some knowledge of the target state prior to sending the commands.  This
knowledge would create a challenging coupling between initiator and target,
but if implemented, would be legal as long as the initiator reordered SCSI
CDB's prior to creating the iSCSI PDU,  keeping its Command SN's in
incrementing order.

If one likens this to parallel SCSI, the SCSI commands are sent to the
target as the initiator receives them.  The target may disconnect if it
chooses, and process the remainder of the command in an order decided by
the target.

iSCSI allows the same; its disconnect is implicit; and target reordering is
allowed at the SCSI processing layer.

By the Way, TCP ensures ordering on a single connection.  In practice,
command ordering doesn't really come into play unless one is in a
multi-connection scenario.

regards,

david

David J Cuddihy, Principal Engineer
ATTO Technology, Inc.
http://www.attotech.com/bridge.html

                    dan yo                                                                
                    <ipsandude@yah       To:     [email-masked]                             
                    oo.com>              cc:                                              
                    Sent by:             Subject:     [Ips] iSCSI cmd ordering and tagged 
                    ips-admin@ietf        task                                            
                    .org                                                                  

                    11/19/2003                                                            
                    12:03 AM                                                              

It seems that the iSCSI requirement of preserving command ordering would
reduce the benefit of the "tagged" tasks feature in SCSI.  For instance, if
a host has several I/O tasks to send to the target and that the ordering is
not important, it may want to tag them as "Simple" and let the target
rearrange them in a way that is optimal to disk access.  However, when
these tasks arrive out of sequence at the iSCSI target side (different from
the order in which they enter the iSCSI layer at the initiator side), they
will be held up to wait for their predecessor to arrive before they can be
delivered to the SCSI target.  This will a bigger issue with the multiple
connections per session scenario in iSCSI where commands from different
connections will get out of order more often than not.&n! bsp; Is my
concern valid?
Thanks,
Dan

Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: Ming Zhang <[email-masked]>
Date: Wed, 19 Nov 2003 09:58:49 -0500

> them in order, so, again, any reordering that happens at the target device
but it is possible that even the initiator can send multiple outstanding
commands via multiple connections on one LUN, the cmd with larger CmdSN
has to wait the the cmd with smaller CmdSn to come in queue before it
can be processed by target.

ming

-- 
---------------------------------------------------
| Ming Zhang, PhD. Student
| Dept. of Electrical & Computer Engineering
| College of Engineering
| University of Rhode Island
| Kingston RI. 02881
| e-mail: mingz at ele.uri.edu
| Tel. (401) 874-2293
| Fax. (401) 782-6422
| http://www.ele.uri.edu/~mingz/
---------------------------------------------------

---

From: Paul Koning <[email-masked]>
Date: Wed, 19 Nov 2003 16:12:47 -0500

>>>>> "dcuddihy" == dcuddihy  <[email-masked]> writes:

 dcuddihy> Dan,

 dcuddihy> This is not really a limitation since iSCSI allows commands
 dcuddihy> to be processed, and status returned, in a different order
 dcuddihy> than they were received.  Multiple outstanding commands to
 dcuddihy> the same lun are accepted as long as they are within the
 dcuddihy> command window (Max Command Sn - Expected Command SN. )
 dcuddihy> iSCSI allows tagged commands to be reordered by the target
 dcuddihy> for efficiency's sake.  One could assume that the initiator
 dcuddihy> is sending them in order, so, again, any reordering that
 dcuddihy> happens at the target device side is legal.

That's not quite right.

SCSI (not iSCSI) can process and complete commands in any order,
subject to restrictions imposed by tagging.  But the transport (iSCSI)
is required to deliver the (non-immediate) commands to SCSI in CmdSn
order (see section 3.2.2.1).

So if you have multiple connections per session, with different
latency on the connections, then the target has to shuffle the
commands back into CmdSn order.  As soon as it has a complete sequence
of commands, it can hand them all to SCSI for action.

Given that typical storage latency is substantially larger than LAN
latency skew, the delay cost of this enforced order is not all that
large.  But it is real (and it also shows up in implementation
complexity in the iSCSI target layer).

	   paul