RE: iSCSI: Out Of Sequence due to null sequence with multiple connections.

[Black_David@emc.com]

> The only concern with that solution is that it may delete
> a whole lot of unrelated SCSI I/O tasks as the sequencer cmdSN
> moves way up to the cmdSN of the task_mgmt command.  "Abort task" 
> as such will not exist in the iSCSI world.   These unrelated 
> commands will now have to be retried by the initiator.  

FWIW, that's not a necessary consequence of the proposal to use
a flag instead of a zero CmdSN, although it does appear to be the
way that Doug envisions implementing this.

--David

> -----Original Message-----
> From:	Sandeep Joshi [SMTP:sandeepj@research.bell-labs.com]
> Sent:	Friday, April 06, 2001 6:29 PM
> To:	Black_David@emc.com
> Cc:	ips@ece.cmu.edu
> Subject:	Re: iSCSI: Out Of Sequence due to null sequence with
> multiple  connections.
> 
> Black_David@emc.com wrote:
> > 
> > Sandeep,
> > 
> > > Still wading thru related emails but I believe that if a refCmdSN
> > > is added to the task management PDU (not present currently but
> > > could be added for task-related management commands), then it
> > > might fix the above-mentioned flaws and allow for safe execution
> > > and immediate delivery of the abort task to the target.
> > 
> > I think this is a functional subset of Doug Otis's suggestion to always
> > use a CmdSN and add a header flag indicating that the command should
> > be executed immediately at the target rather than waiting for those with
> > prior CmdSNs to arrive.  Doug's suggestion also consumes less space
> > in the header. 
> 
> Yes, i now understand Doug's proposal.  The "PDU sequencer" was
> new terminology which baffled me some.. :-)
> 
> His solution does seem like a cleaner approach (no target state)
> 
> In some ways, it reminds one of the M_FLUSH function used
> in the STREAMS layer.   If we stand back a bit, we see that the
> scenario is essentially the same -> Stream module processing is 
> normally asynchronous.   With M_FLUSH, the stream head desires to 
> clean out all the downstream module queues.  
> 
> The only concern with that solution is that it may delete
> a whole lot of unrelated SCSI I/O tasks as the sequencer cmdSN
> moves way up to the cmdSN of the task_mgmt command.  "Abort task" 
> as such will not exist in the iSCSI world.   These unrelated 
> commands will now have to be retried by the initiator.  
> 
> Do we have any numbers on how often ABORT_TASK/ABORT_TASK_SET actually 
> occurs in filesystem/SCSI workloads ?
> 
> regards,
> -Sandeep