Subject: RE: iSCSI: Out Of Sequence due to null sequence with multiple con nections.

From: [email-masked]
Date: Fri, 6 Apr 2001 18:08:06 -0400

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.  As to (1) vs. (2):

> (1) The command takes effect immediately and its status/response
>         is available immediately.
> (2) The command affects all commands in flight, and its status/response
>        is delayed until all such effects are complete.

I think you've covered most of the ground in:

> 6) Task response can be returned as appropriate to conform with
>    SAM2 - either after in-flight commands arrive or immediately
>    since the target knows what needs to be done later.  I am slightly 
>    confused here since your goals (1)&(2) appear to be contradictory
>    for application to in-flight commands.. it depends on semantics 
>    what "taking effect" implies ?

IMHO, returning the response before task execution is complete
("the target knows what needs to be done later") not only does
not comply with SAM2, but can also yield rather unexpected
behavior (e.g., situations in which an in-flight command is aborted
significantly after the response to the abort command has been
returned to the Initiator).  If this is correct, goals (1) and (2) are
contradictory because there's only one response and achieving
both goals requires sending that one response at two different
times (not a good idea).  Hence the Initiator has to choose
between (1) and (2) for each task management command.

Thanks,
--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, 6 Apr 2001 17:29:55 -0700

Sandeep,

I understand your concern as you view the sequencer as potentially holding
an inordinate amount of commands.  Flow control should help keep this queue
lean.  Consider the consequence of a connection failure creating a series of
holes in the sequence.  The alternative to an immediate rejection of
commands may be to time-out on each hole in the sequencer.  In this case,
resending a list of rejected commands is a better solution than an endless
sequence of timeouts if this queue is really that large.  Data wise, this
list should represent only a small amount to be resent.  If the CmdSN was
not session but LUN wide, then there would be less recovery.  I do not see
this happening often enough for there to be a concern about the number of
commands rejected.

Doug

> [email-masked] wrote:
> >
> > Sandeep,
> >
> > 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
>

---

From: Sandeep Joshi <[email-masked]>
Date: Fri, 06 Apr 2001 18:29:25 -0400

regards,
-Sandeep