On Oct 19, 2007, at 8:03 AM, Eddy Quicksall wrote:
Julian, below you said "no" to #2. But is there a restriction in the RFC (maybe I just don't remember it)? I agree it has no practical value but I have used it to test my re-ordering logic with only one connection.
Parav quoted a MUST from the RFC on this, so I'd call that a restriction. :-)
I agree that it's a reasonable thing to do to test re-ordering logic. But I think that test environments don't count in that to be a good test of error handling, they _must_ break the spec. :-) Otherwise it's exceptionally difficult to reproducibly test how devices handle error conditions. :-)
Take care,
Bill
---- Original Message -----
Sent: Friday, August 31, 2007 11:53 AM
Subject: Re: rationale to send PDUs in increasing CmdSn onsingle connection
Parav Pandit <paravpandit@xxxxxxxxx> wrote on 31/08/2007 12:52:04:
> Hi,
>
> RFC 3720, section 3.2.2.1 says
>
> "On any connection, the iSCSI initiator MUST send the
> commands in increasing order of CmdSN, except for
> commands that are retransmitted due to digest error
> recovery and connection recovery. "
>
> (Assuming Single TCP connection ISCSI session)
>
> 1. I interpret above 3.2.2.1 statement as
> SCSI layer gives SCSI commands to the ISCSI stack in
> the order of Cmd-1 and Cmd-2.
> Cmd-1 will have CmdSn = 10.
> Cmd-2 will have CmdSn = 11.
> ISCSI stack CAN send PDUs to the TCP layer in
> following order ONLY.
> PDU-1 with Cmd-1.
> PDU-2 with Cmd-2.
>
> Is this correct interpretation?
> Or
>
Yes
> 2. On a SINGLE connection can ISCSI stack send the
> PDU-1 with Cmd-2 followed by
> PDU-2 with Cmd-1?
>
NO
> Assuming the answer of the question #2 is No,
>
> 3. If there are multiple connections in a session then
> command MAY any way reach out of order. And targets
> need to wait for the previous expected commands.
>
> So targets will receive out of order ISCSI PDUs from
> the TCP layer and ISCSI stack handles them.
>
> So then why initiators have restriction of sending
> command in the increasing order of CmdSn on SINGLE TCP
> connection?
>
To simplify recovery and to...
> Is it to simplify the implementation of targets
> supporting only single TCP connection?
>
>
and there was no visible motivation for out of order commands on a single connection
