Re: iSCSI-related conclusions from Orlando interim Meeting

[julian_satran@il.ibm.com]

Santosh,

I am not sure that I understand your points.

   Point c - is irrelevant as task management function are just that task
   management functions and not commands (i.e., have no ordering, queueing
   etc. associated with its SCSI execution)
   we choose to get a task management function a task-id only to simplify
   request response handling in the iSCSI layer - and not because there is
   a SCSI task context associated with it
   the side effects that David (Black) was referring I think are the
   following:
     if at the target you get to abort a task that has not arrived yet and
     since you are bound to use service response function complete you
     should (at the target) dutifully note the referenced-id and abort it
     when it arrives - as you are forbidden (by SAM) to send any more
     responses for this task; this may lead to interesting cleanup problem
     if the referenced id was never sent - and you will have to handle this
     (practically you can remove the mark when CmdSN arrives or after an
     interval if you don't have a CmdSN and either inform or not the
     initiator)
     if at the target you get a clear task set you may end not clearing
     tasks you where supposed too or clearing tasks you where not supposed
     too (as there is no ordering implied)
   The solution suggested - order the task management at iSCSI level is
   straightforward
     task management functions request can be delivered to SCSI and
     executed IMMEDIATELY and the CmdSN they carry should be viewed only as
     a "boundary" for their applicability



Immediate delivery was meant to be used in cases in which you are confident
that ordered delivery does not matter. This might be a drastic action (like
target rest) or things that we did not consider yet.

Julo



Santosh Rao <santoshr@cup.hp.com> on 22/01/2001 02:05:22

Please respond to Santosh Rao <santoshr@cup.hp.com>

To:   Black_David@emc.com
cc:   ips@ece.cmu.edu
Subject:  Re: iSCSI-related conclusions from Orlando interim Meeting




> - Abort WARNING will be added to the draft.
> - Immediate Delivery of Aborts and similar task management commands
>   may have unexpected results when multiple TCP connections are in use
>   because Abort, Clear Task Set, etc. may bypass command(s) to be
>   aborted/cleared on other TCP connections.
> - Ordered Delivery should be used instead when this is a concern.

Is the above referring to ordered delivery as in CmdSN based ordering or
the use of the Ordered Task Tag ?

I see the following issues with this :

a) CmdSN defines the order of delivery from the iSCSI layer to the SCSI
   ULP at the target.

   Abortion of active tasks will involve the invalidation of the
   SCSI State information [being accessed by either adapter micro-code
   or the FPGA/ASIC] maintained for these tasks.
   This process is kicked off in the iSCSI layer and this abort
   functionality in the iSCSI layer will also need to be subject to the
   ordering constraints of CmdSN. (in addition to the ordering of delivery
   to the SCSI ULP).

b) A received Task Management command [on, say, connection 'x']
   cannot be performed due to previous CmdSNs not yet
   having arrived. (In the case where another connection 'y' in the
   session is faulty and CmdSNs sent on connection 'y' have'nt arrived).

c) Ordered Task Tags should not be used with error recovery Task
   Management commands, since this can result in a deadlock of the task
   mgmt command in case the older tasks are'nt completing in the SCSI ULP
   due to some ULP problem. ("An Ordered Task cannot enter the enabled
   state until all older tasks have completed.")

d) Given that Immediate command delivery (CmdSN of 0) is un-usable for
   task management commands, is there any other application for this
   feature? If not, all references to it can be removed from the draft and
   CmdSN can start from 0.

Regards,
Santosh

--
#################################
Santosh Rao
Software Design Engineer,
HP, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
#################################