RE: aborting an out of sequence cmdSN

[Charles Monia <cmonia@NishanSystems.com>]

Hi:

> > Does iSCSI have a way to abort the commands that are in the 
> target but not
> > yet in the SCSI Target Layer?
> 
> No, it doesn't.  Part of the problem is that just considering
> iSCSI info, the Initiator can't tell whether such commands
> are in the Target vs. still in-flight.  TCP ACK info may help,
> but if TCP hasn't ACKed, the Initiator still doesn't know.
> 

I don't understand what problem is being addressed.

I assume that iSCSI is just an extension of the pipeline for SCSI commands
and task management functions.  As long as nothing impedes pipeline flow,
the appropriate operations should eventually be presented to the SCSI layer
for execution in the proper order.

I thought it was decided a long time ago that the SCSI layer would interact
with the iSCSI transport such that flow through the pipeline never blocked
indefinitely.

Is that the case?

Charles
> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Tuesday, April 17, 2001 12:03 AM
> To: Eddy@quicksall.com; ips@ece.cmu.edu
> Subject: RE: aborting an out of sequence cmdSN
> 
> 
> Eddy,
> 
> > Does iSCSI have a way to abort the commands that are in the 
> target but not
> > yet in the SCSI Target Layer?
> 
> No, it doesn't.  Part of the problem is that just considering
> iSCSI info, the Initiator can't tell whether such commands
> are in the Target vs. still in-flight.  TCP ACK info may help,
> but if TCP hasn't ACKed, the Initiator still doesn't know.
> 
> This is the issue that Doug's been posting about, advocating
> that iSCSI always reject all commands prior to the task abort
> on the assumption that the initiator can reissue them - given
> the lack of support this has received, I'm going to take this
> opportunity to state that I believe WG rough consensus exists
> for NOT pursuing this "reject all prior commands" approach.
> This is the last chance for anyone else to express support for
> this reject-based approach.
> 
> If we were to address the original issue, I think some sort
> of new mechanism is needed at the iSCSI level, as the
> attempts to use a side effect of SCSI task aborts don't
> seem to be getting much of anywhere (e.g., a previous
> attempt at this involved having iSCSI automatically send
> task management commands multiple times).  A SWAG at what
> such a mechanism might look like is some sort of iSCSI
> "Cancel" that names the CmdSN(s) to be cancelled and sent
> in the same PDU as the SCSI Task Abort or Task Set Abort
> that is supposed to abort them.  Canceling would apply
> both to commands waiting for CmdSN in iSCSI as well as
> those not yet received by the target (i.e., the target
> has to have some notion of "pending cancel" for commands
> it hasn't received yet.  The cancelled commands
> probably have to return some sort of iSCSI service error
> rather than SCSI sense data.  Something like this looks
> like it can be made to work as desired (issue TASK 
> ABORT with the corresponding Cancel for immediate delivery,
> and if SCSI declares the TASK ABORT to have succeeded,
> then that command will not subsequently execute), but it'll
> add complexity.  Is that worth the benefit of being able
> to reach out and definitively strangle an errant command?
> 
> --David
> 
> > -----Original Message-----
> > From:	Eddy Quicksall [SMTP:Eddy@quicksall.com]
> > Sent:	Friday, April 13, 2001 6:40 PM
> > To:	Ips@Ece. Cmu. Edu (E-mail)
> > Subject:	aborting an out of sequence cmdSN
> > 
> > 
> > If a command is received out of sequence, it is not passed 
> to the SCSI
> > Target Layer. So, it must be queued waiting for the prior 
> command. Now, if
> > the prior command never comes the operating system may 
> attempt to abort
> > the
> > lost command by sending an abort to the driver.
> > 
> > The abort can't be turned into an ABORT TASK TMF because 
> the target iSCSI
> > has not acknowledged that it has received the original 
> command yet. And,
> > even if the ABORT TASK was sent, it can't get to the SCSI 
> Target Layer
> > because its cmdSN will be higher than the most recent command.
> > 
> > The iSCSI initiator drive could just jerk it out of its 
> queue (knowing
> > that
> > it hasn't been acknowledged yet) but then the iSCSI target may still
> > execute
> > it when the missing PDU's arrive.
> > 
> > Does iSCSI have a way to abort the commands that are in the 
> target but not
> > yet in the SCSI Target Layer?
> > 
> > Eddy
> > 
>