Subject: RE: iscsi: rev 05 2.5.1 requires ACA support

From: [email-masked]
Date: Fri, 16 Mar 2001 21:44:40 -0500

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
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: Douglas Otis <[email-masked]>
Date: Fri, 16 Mar 2001 22:30:19 -0800

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