RE: iscsi: rev 05 2.5.1 requires ACA support

[Douglas Otis <dotis@sanlight.net>]

David,

Even with management commands, position within the command stream is
assumed.  Should there be commands sent without an ability to verify
relative position and with the potential for excessive skews between
connections, the use of a zero seems clumsy.  It could apply to command not
yet received on different connections.  Even though a command may have a
sequence value, it could be 'Marked' for immediate use without strict
adherence to sequence.  The sequence value could be used to filter late
comers, perhaps the cause for the management command in the first place.
The task attribute could be used to understand if there is a need for
immediate application or an iSCSI specific bit if that is too difficult.

Doug

> Considering Charles's first two problems:
>
> > - problem 1) When an initiator's I/Os are cleared by it own
> actions (e.g.
> > sending a task management function of abort task set) how does it know
> which
> > of issued commands were aborted and which were still in-flight
> and had not
> > yet made it to the target.
>
> Ordered delivery solves this one, but can cause:
>
> > - problem 2) (closely related to 1)  How are task management functions
> > delivered - with the immediate delivery option (CmdSN=0) or not?
> (reference
> > 1.2.2.1, top of page 12)  If immediate, then problem 1 is aggravated if
> > multiple connections are used.  If not immediate, then we can have a
> problem
> > with the task management function never being delivered because
> the I/O we
> > are trying to abort never made it to the target and the target's iSCSI
> layer
> > wont' pass up the task management function because the CmdSN number is
> > wrong.
>
> And this could be even worse if the I/O to be aborted made it to
> the target,
> but some other I/O is stuck in a connection and hence holding up the task
> management function, even though one or more commands to be aborted
> are merrily executing.
>
> > + solution to 1 and 2) I propose all task management functions
> be required
> > to use the  following:
> >   - immediate delivery option
> >
> >   - utilize a new task management function sequence number
> field (call it
> > TskMgmtSN)
> >
> >   - all task management functions shall be sent on all active
> connections
> > with the same value for TskMgmtSN
> >
> >   - the target must receive the same task management function
> (identified
> by
> > TskMgmtSN) on all active connections before it acts on it.  (Use a timer
> > (TBD) to weed out and close down defective connections.)
>
> The target still has to receive the task management
> command on the slow connection, or time out and close
> the slow connection before it can execute the task
> management command.  This is vulnerable to the
> "arbitrary delay by some unrelated command" version
> of problem 2).
>
> If both problems need to be solved, the task management
> command may have to be sent at least twice when there
> are multiple connections active:
> - With immediate delivery to take effect as soon as
> 	possible.
> - With ordered delivery to ensure that everything it
> 	is supposed to affect has made it to the target.
>
> My reaction to this entire area that having iSCSI do
> any duplication of task management commands
> transparently to SCSI is introducing a bunch of extra
> complexity that doesn't seem to deliver a lot of
> extra value.  Any user of iSCSI already has to decide
> between immediate and ordered delivery, and the
> less we muck with the task management commands,
> the more likely the user will be able to obtain
> desired/expected/understood behavior.
>
> Comments?
> --David
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>
>