Re: iSCSI: ordered command delivery at the target

["Mallikarjun C." <cbm@rose.hp.com>]

Amir and Julian are correct.  I see a lot of mistaken notions in this note,
and IIRC, this was discussed several times in the past.

The SCSI Architecture Model defines the data transfer protocol services
that are invoked by the SCSI ULP to drive the data transfers - thus technically
letting an instantiated SCSI task to perform data transfers.  CmdSN is relevant
only *before* the task is instantiated.  BTW, initiator ULP timeouts are exactly
meant to take care of the "network latency" issues.

AFAICT, assigning CmdSN to SNACK would lead to a lot more complexity 
(issuing SNACKs to recover lost SNACKs and....), and I don't see what the 
issue is now.

Needless to say, I would not recommend either of these.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com

----- Original Message ----- 
From: "Luben Tuikov" <luben@splentec.com>
To: "Julian Satran" <Julian_Satran@il.ibm.com>
Cc: "Amir Shalit" <amir@astutenetworks.com>; "iSCSI" <ips@ece.cmu.edu>
Sent: Friday, June 07, 2002 10:43 AM
Subject: Re: iSCSI: ordered command delivery at the target


> Julian Satran wrote:
> > 
> > Luben,
> > 
> > Amir is right. The text says explicitly that CmdSN has no significance whatsoever after delivery
> > to SCSI (when the task is instantiated).
> > ITT is the only means to identify safely a task. As for the difficulty of search for the ITT -
> > that is all a question of implementation prowess
> > (i.e., it should not e as difficult as you make it sound).
> 
> Julian,
> 
> I'm talking about Data-Out PDU's. CmdSN is NOT advanced
> for Data-Out PDU's, only _copied_ from the original task/command.
> 
> A task CANNOT be delivered to the device server
> without all data being available at the target,
> being the case that there could be a huge
> network (Ethernet) latency. Once all data has
> arrived, then the task is delivered to the
> device server (LL SCSI) and CmdSN becomes irrelevant.
> 
> Furthermore, CmdSN is NOT advanced on sending
> Data-Out pdu's -- it is just copied there
> from the original task/command.
> 
> The whole point of this is making
> inserting into the ``incoming'' priority
> queue ordered.
> 
> When the task is moved into a ``pending for more data'' queue,
> this would naturally make the Data-out PDUs immediate
> PDUs, as they should be. When Data-Outs arrive at the
> target, CmdSN has advanced by at least k*** since the task has been
> just _received_, and any ``older'' Data-Out PDUs (carrying the same CmdSN)
> will go to the front of the ``incoming'' queue and be seen immediately.
> 
> *** If k = 0, then the task is still in the ``incoming'' queue
> and the Data-Out is sorted right after it -- same effect.
> 
> Furthermore, the target will NOT allow CmdSN wrapping
> for an outstanding task (one for which data is being delivered, I->T,
> in order to be sent to the device server (SCSI), _only_ after which
> CmdSN becomes irrelevant, but this means that all data was
> delivered....).
> 
> Do you see it?
> 
> -- 
> Luben
> P.S. CmdSN wrapping MUST not depend on the choice of
> maximum data segment. The suggestion I posted preserves
> this reservation.
>