SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: StatSN and overlapped commands


    • To: "Ips (E-mail)" <ips@ece.cmu.edu>
    • Subject: RE: StatSN and overlapped commands
    • From: Charles Monia <cmonia@NishanSystems.com>
    • Date: Thu, 7 Aug 2003 16:22:25 -0700
    • Content-Type: text/plain;charset="iso-8859-1"
    • Delivered-To: ips-outgoing@sos.ece.cmu.edu
    • Delivered-To: ips-outgoing@ece.cmu.edu
    • Delivered-To: ips@sos.ece.cmu.edu
    • Delivered-To: ips@ece.cmu.edu
    • Sender: owner-ips@ece.cmu.edu

    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
    > 
    


Home

Last updated: Thu Aug 07 20:19:25 2003
12794 messages in chronological order