RE: rationale to send PDUs in increasing CmdSn on single co nnection
there was no visible motivation for out of order commands on a single
On the contrary, there was plenty of motivation. It was
overridden by the desire for simplified implementations over single TCP
connections as the Parav conjectured. There are DMA related efficiencies that
can be realized in situations with a mix of solicited and immediate/unsolicited
I/O traffic. The folks in favor of this optimization were outvoted by those who
wanted to simplify their single connection based
Parav Pandit <paravpandit@xxxxxxxxx>
wrote on 31/08/2007 12:52:04:
> RFC 3720,
section 184.108.40.206 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
> 1. I interpret above 220.127.116.11 statement as
SCSI layer gives SCSI commands to the ISCSI stack in
> the order of Cmd-1
> Cmd-1 will have CmdSn = 10.
> Cmd-2 will have CmdSn =
> ISCSI stack CAN send PDUs to the TCP layer in
> PDU-1 with Cmd-1.
> PDU-2 with Cmd-2.
Is this correct interpretation?
> 2. On a SINGLE connection can ISCSI stack send the
PDU-1 with Cmd-2 followed by
> PDU-2 with Cmd-1?
> Assuming the answer of the question
#2 is No,
> 3. If there are multiple connections in a session
> 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
> So then why initiators have restriction of
> command in the increasing order of CmdSn on SINGLE TCP
To simplify recovery and
> Is it to simplify the implementation of targets
only single TCP connection?
and there was no visible
motivation for out of order commands on a single connection
> Parav Pandit
Looking for a deal? Find great prices on flights and hotels with
Ips mailing list