Re: Task management questions

["Julian Satran" <Julian_Satran@il.ibm.com>]

John,

For some reason Gwendal's input did not reach me (is he subscribed to 
ips?).
As for reading - the text is meant as a guide for the implementer and is 
not for casual reading.
It was already updated with input from two implementers (IBM and Matthew 
Burbridge from HP).
The barrier mechanism in 9.4 is the iSCSI barrier meant to discard 
commands that have not been delivered yet to SCSI (and thus avoid having 
them start execution).  It has to be read carefully as it involves two 
mechanism - an initiation and actions to be done when ExpCmdSN changes.

I will add some wording to 3.5.1 to the effect that it refers to commands 
that have reached SCSI (where past the iSCSI barrier).
The action mandated is meant to enable ITT recycling (making sure that a 
task gets status even if this status will not be delivered to SCSI at 
initiator).

Regards,
Julo







John Hufferd/San Jose/IBM@IBMUS
Sent by: owner-ips@ece.cmu.edu
25-11-01 01:32

 
        To:     "ips" <ips@ece.cmu.edu>
        cc:     Gwendal Grignou <ggrignou@silverbacksystems.com>
        Subject:        Re: Task management questions

 


I think Gwendal has a point.  This and section 9.4 are very hard sections
to read and understand.  Perhaps we did not mean all that is said here.

In addition too, or in support of Gwendal, I also found that the paragraph
that begins  "For all these Functions..." in 3.5.1 needs to be Harmonized
with the "Abort Task Must..." Paragraph since they are clearly at odds,
especially since the Abort Task is one of the functions addressed in the
previous paragraph.  But I simply do not understand how the following
statement:

"...the target MUST deliver to the initiator good status for all aborted
task for which no status was delivered yet. The task management response
MAY be issued by the target immediately after marking all tasks to be
aborted."

can be made to work with section 9.4 which goes to great pain to "silently
discard" commands that are covered by the Abort but have not yet been
executed.  (See the last item b on  page 156.)  I think silently discard
means do not return Status.

After we sort out the above, we still have to deal with the differences
right within  9.4.  That is the first item d on page 156 states:

"Note: Any entries that had been marked as a candidate for cleanup have 
now
been delivered by the target to its SCSI layer. The SCSI layer will have 
to
determine if they are to be aborted."

and the last item b states:

"remove the oldest barrier list item and evaluate all queued entries that
have a CmdSN field less than ExpCmdSN, removing and silently discarding
each queued command that meets the criteria for cleanup candidacy (as
specified by the task management function)"

This means DO NOT SEND THEM TO SCSI !   Therefore, they had not been
delivered by the target to its SCSI layer as stated above.

So we have one place saying that SCSI layer will determine, and the other
place finding a method not to send them to SCSI.

I understand what is being attempted here (to meet the requirements of
SAM-2 (1157-D) section 5.5.2 that states "... no notification that the
task(s) have been aborted shall be returned to the initiator...." however,
our documentation needs some clean-up to make it consistent.

This is NOT a  change to the protocol, just a clean up of our
documentation, but the way it is now it is hard to perform the protocol 
and
follow the documentation in this specific area.



.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com


Gwendal Grignou <ggrignou@silverbacksystems.com>@ece.cmu.edu on 11/23/2001
02:03:02 PM

Sent by:  owner-ips@ece.cmu.edu


To:   "ips" <ips@ece.cmu.edu>
cc:
Subject:  Task management questions



I have a question about the section 3.5.1 page 69.
The paragrah starting with "ABORT TASK MUST",the last sentene says "The
task
management response MUST be issued after the command status (if any) was
issued." : it means the initiator will receive, on the same connection, a
status for the aborted task and AFTER, a response for the task management
function.

In the paragraph before (starting with "For all these functions,",), it is
specified that the target should send a status for all aborted tasks, but
the
task management response can happen at any time after the task management
request has been received by the target "The task management response MAY
be
issued by the target immediately after marking all tasks to be aborted."

Why such a difference between "ABORT TASK" function and other functions ?

About, "LOGICAL UNIT RESET", it is stated "the target MUST behave as
dictated
by the Logical Unit Reset function in [SAM2]." However, in SAM2, taks
should
be aborted as described in section 5.6 of SAM2, which says , in section
5.6.2, about initiator aborting their own task "When an initiator causes
its
own task(s) to be aborted, no notification that the task(s) have been
aborted
shall be returned to the initiator other than the completion response for
the
command or task management function action that caused the task(s) to be
aborted and notification(s) associated with related effects of the action
(e.g., a target reset unit attention condition)." Does it means the iSCSI
target may not send a status for the aborted tasks in case of a
"LOGICAL UNIT RESET" ? (and subsequently for TARGET RESET [WARM or COLD]
which triggers LOGICAL UNIT RESET for each LUs [SAM2, section 5.8.6]). It
does not match with the requirement in the paragraph concerning all the
task
management functions in general.

Can you elaborate more on those requirements ?

Thanks a lot,

Gwendal.