RE: StatSN and overlapped commands

[Charles Monia <cmonia@NishanSystems.com>]

Hi:

For the record:

Target enforcement of tag uniqueness was not required due to the amount of
potential work and/or complexity along with the impact on target
performance.

Charles

> -----Original Message-----
> From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
> Sent: Thursday, August 07, 2003 3:41 PM
> To: Julian_Satran@il.ibm.com; pat_thaler@agilent.com
> Cc: Black_David@emc.com; dcuddihy@attotech.com; ips@ece.cmu.edu;
> julian@cs.haifa.ac.il; owner-ips@ece.cmu.edu; satran@haifasphere.co.il
> Subject: RE: StatSN and overlapped commands
> 
> 
> Julian,
> 
> I have done some checking. Even for tasks that are in 
> progress, neither the SCSI Architecture model nor iSCSI have 
> any requirement that the target check that task tags from the 
> initiator are unique. It is up to the initiator to ensure 
> that the task tag is unique within the nexus. In the Fibre 
> Channel world, FCP actually has an explicit statement that 
> the target can rely on them being unique and isn't required 
> to check for overlap.
> 
> It isn't the target's job to keep the initiator from messing 
> up its use of task tags. If an initiator isn't using tags 
> properly, there are plenty of other mistakes it can make that 
> will cause problems and that the target can't detect.
> 
> Of course, as Bill and others have said, a target may check 
> ITTs for overlap even though it isn't required to.
> 
> Pat
> 
> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Wednesday, August 06, 2003 1:26 PM
> To: pat_thaler@agilent.com
> Cc: Black_David@emc.com; dcuddihy@attotech.com; ips@ece.cmu.edu;
> julian@cs.haifa.ac.il; owner-ips@ece.cmu.edu; satran@haifasphere.co.il
> Subject: RE: StatSN and overlapped commands
> 
> 
> Pat,
> 
> If Status (if required) has to be sent with an associated ITT 
> (it is the 
> only way an initiator has to associate a status with a task). 
> If the ITT 
> happens to be that of a new task this association may be 
> incorrect. Recall 
> that error scenarios can be complex (with some missing 
> statuses and even 
> connection failover). 
> For all those reason a target accepting recovery must 
> "protect" any ITT 
> included in unacknowledged status.
> 
> End-of-thread.
> Julo
> 
> 
> 
> pat_thaler@agilent.com 
> Sent by: owner-ips@ece.cmu.edu
> 06/08/2003 21:02
> 
> To
> satran@haifasphere.co.il
> cc
> julian@cs.haifa.ac.il, Black_David@emc.com, dcuddihy@attotech.com, 
> ips@ece.cmu.edu
> Subject
> RE: StatSN and overlapped commands
> 
> 
> 
> 
> 
> 
> Julian,
> 
> For recovery, the target has to remember the status, but that 
> doesn't mean 
> it has to keep the task information around. It would have the status 
> message linked to StatSN but it would be typical to clear 
> away any task 
> context when that message is generated. Remember that when 
> things are very 
> busy it might get a single acknowledgement that acknowledges multiple 
> status messages from multiple tasks. It isn't efficient to 
> have to go back 
> to do the task context clean up when the status ack comes. 
> 
> It is the initiator's job to not shoot itself in the foot by 
> issuing a new 
> command with the same task tag as one that it hasn't gotten 
> status on yet. 
> For the target, once the status is generated, the task is 
> gone. The status 
> message may still be there available for a resend, but the 
> task is gone. I 
> don't see any requirement in iSCSI or SCSI to do anything 
> other than that.
> 
> Regards, 
> Pat
> 
> -----Original Message-----
> From: Julian Satran [mailto:satran@haifasphere.co.il]
> Sent: Tuesday, August 05, 2003 8:48 PM
> To: THALER,PAT (A-Roseville,ex1)
> Cc: julian@cs.haifa.ac.il; Black_David@emc.com; dcuddihy@attotech.com;
> ips@ece.cmu.edu
> Subject: Re: StatSN and overlapped commands
> 
> 
> pat_thaler@agilent.com wrote:
> 
> > Julian,
> > 
> > I agree that the initiator is misbehaving, but I don't 
> agree that the 
> target should detect that misbehavior. The target SCSI layer 
> thinks the 
> command was done when it generated the status. As David said, 
> the target 
> keeps the status around so that it can resend it if requested 
> by Status 
> SNACK. It doesn't need to keep track of the tag anymore at that point.
> > 
> > If the target had to generate an error when a command came 
> with for a 
> tag before the status for a prior command with the same tag was 
> acknowledged, then it would have to clear the memory of tags 
> when status 
> acks came in which is less efficient than doing it when posting the 
> status.
> > 
> > Pat
> > 
> > -----Original Message-----
> > From: Julian Satran [mailto:julian@cs.haifa.ac.il]
> > Sent: Tuesday, August 05, 2003 10:56 AM
> > <snip>
> > 
> >>
> >>No, iSCSI at the target is retaining the SCSI status of the 
> completed
> >>command for retransmission.  SCSI believes the command to 
> be completed,
> >>and any retransmission request (e.g., Status SNACK) is not 
> visible to
> >>SCSI at the target.  In this case "command recovery" does 
> not execute
> >>any commands at the target; it just causes retransmission 
> of the saved
> >>status.
> >>
> >>Thanks,
> >>--David
> >>----------------------------------------------------
> >>David L. Black, Senior Technologist
> >>EMC Corporation, 176 South St., Hopkinton, MA  01748
> >>+1 (508) 293-7953             FAX: +1 (508) 293-7786
> >>black_david@emc.com        Mobile: +1 (978) 394-7754
> >>----------------------------------------------------
> >>
> > 
> > My only caveat to this would be that an initiator that reuses the 
> > Initiator Task Tag but does not acknowledge the reception 
> of the status 
> > by an ExpSataSN is definitely misbehaving.
> > 
> > The target should not consider it as an implicit ack (as 
> intermetiate 
> > status PDUs may have been lost - it should reject the command that 
> > reuses the Initiator Task Tag.
> > 
> > That is not necesarily related to the way an initiator maps 
> SCSI tags to 
> 
> > iSCSI tags - it is specific to iSCSI expectations about tag reuse.
> > 
> > You correctly stated that an iSCSI tag should not be reused 
> before it's 
> > status is acknowledged but violating this rule is an iSCSI protocol 
> > error and not a SCSI error (overlapped command).
> > 
> > Julo
> > 
> Pat,
> 
> The target has to remember the status the status for recovery 
> - if both 
> I and T have agreed on recovery. If it drops it some recovery 
> scenarios 
> won't work.
> 
> You are right that when no recovery is agreed status can be 
> dropped but 
> not so if recovery is agreed. And while within connection recovery is 
> not based on ITT a recovered status containing a wrong ITT is 
> not a good 
> idea!
> 
> Julo
>