Yet Another SAM-5 Command Timeout Subproposal for 14-107

George Penokie george.penokie at avagotech.com
Mon Jun 2 08:49:15 PDT 2014


Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1406020_nameless-1980-2-1.html">nameless-1980-2-1.html</a>

Paul,
A command that has entered the enabled state never goes back to the dormant
state. From Enabled it can only go to blocked unless it is terminated or
completed.
I agree with Gerry that limiting it to only simple is a bad idea. It should
work with both ordered and simple. That means the timer for any command
that specifies it has to be timed is started when the Dormant state
receives that Command. I would suggest that the timer be set up as a "state
machine variable" (see SPL to find out about those).
The timer should be stopped when the enabled state receives a Send Command
message or an Abort command message.
If the timer is running and an ACA Established message is received the
timer should not be stopped.
If the timer expires while in the Dormant state a message needs to be sent
to TM to tell it to abort the command.
If the timer expires while in the Enabled state a message needs to be sent
to TM to tell it to abort the command and the enabled state should not
respond to any Send Command messages.
If the timer expires while in the blocked state a message needs to be sent
to TM to tell it to abort the command and the blocked state should not
response to any ACA Cleared messages.
Bye for now,
George Penokie
Avago Technologies
3033 41 St NW
Rochester , MN 55901
507-328-9017
george.penokie at avagotech.com
On Fri, May 30, 2014 at 1:29 PM, Gerry Houlder <gerry.houlder at seagate.com>
wrote:
> I wonder if restricting the command timeout feature to "SIMPLE attribute
> only" is necessary. If we add that restriction, then we have to define what
> happens when a command with non-zero GROUP field doesn't have a SIMPLE
> attribute. Is it a frame error (the attribute is in the command frame
> header), a CDB error, or do we ignore the GROUP field whenever the
> attribute is not SIMPLE? We are already restricting the timeout feature to
> only apply to read and write commands (which can be determined from the
> CDB), so maybe we don't need to also restrict it based on the attribute.
>
>
> On Fri, May 30, 2014 at 12:58 PM, Paul Suhler <Paul.Suhler at hgst.com>
> wrote:
>
>>  Thanks, Gerry.  I’d overlooked the possibility of re-entering Dormant.
>>
>>
>>
>> As far as other states, the timeout proposal only applies to commands
>> with the SIMPLE attribute.
>>
>>
>>
>> Paul
>>
>>
>>
>> *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of *Gerry
>> Houlder
>> *Sent:* Friday, May 30, 2014 10:52 AM
>> *To:* T10 Reflector
>> *Subject:* Re: Yet Another SAM-5 Command Timeout Subproposal for 14-107
>>
>>
>>
>> Another side effect that may have to be considered -- a command may be
>> received, to to dormant state, to to enabled state, go back to dormant, go
>> back to enabled several times before it gets processed. You would only
want
>> the transition from Idle to either dormant or enabled to set the timeout
--
>> entering enabled from dormant or dormant from enabled should not
>> recalculate the timeout.
>>
>>
>>
>> On Fri, May 30, 2014 at 12:42 PM, Gerry Houlder <
>> gerry.houlder at seagate.com> wrote:
>>
>>  It seems reasonable to me that the arrival at the CS of a Queue Command
>> message (item c) is a good event to choose as the event that starts the
>> command timer, if any. The other events on your list could either be
>> thought of as 'zero time" or just not accounted for (e.g., part of the
>> service delivery delays that are not accounted for).
>>
>>
>>
>> Note that entry into dormant state only accounts for Queue Command
>> messages received with simple or ordered attribute. You also have to
>> account for Queue Command message that are received with Head of Queue
>> attribute and ACA attribute (these go directly to Enabled state, so you
>> need modifications here to also set the timeout interval, if any).
>>
>>
>>
>> On Fri, May 30, 2014 at 12:07 PM, Paul Suhler <Paul.Suhler at hgst.com>
>> wrote:
>>
>>  It’s been suggested to me that the lack of a roar is because the lion
>> sleeps Wednesday night through Sunday night.
>>
>>
>>
>> I’d like to check my understanding of 14-054r3 and how that affects my
>> proposal:
>>
>>
>>
>> My intent is that a command may time out any time after arrival and
>> before it first requests a data transfer.  In terms of T10/14-054r3, this
>> corresponds to command states LU_CS2:Dormant and LU_CS3:Enabled.  The
>> expiration time is computed when the command first arrives, as indicated
by
>> entry into LU_CS2:Dormant; this assumes that four events take place
>> essentially at the same time, given adequate resources:
>>
>> a)		 Arrival of the command at the SCSI Target Port.
>>
>> b)		 Arrival at the TM of the SCSI Command Received message.
>>
>> c)		 Arrival at the CS of the Queue Command message.
>>
>> d)		 Entry into LU_CS2:Dormant.
>>
>>
>>
>> Is that assumption correct?
>>
>>
>>
>> I’d like not to introduce a new message.  Having specified in the model
>> section the conditions upon which a timeout happens, can I just specify in
>> the descriptions for LU_CS2 and LU_CS3 what happens when the timeout
>> occurs?  This would be analogous to the description of the LU_DS state,
>> which specifies what happens when an error occurs during command
processing
>>
>>
>>
>> Or is a message to those states necessary?
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Paul
>>
>>
>>
>> *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of *Paul
>> Suhler
>> *Sent:* Thursday, May 29, 2014 9:31 AM
>> *To:* T10 E-mail Reflector (t10 at t10.org)
>> *Subject:* More: SAM-5 Command Timeout Subproposal for 14-107
>>
>>
>>
>> Okay, that attempt to provoke the lions’ den did not evoke any roars, so
>> it must have been acceptable, *n’est pas*?  So, here’s another try:
>>
>>
>>
>> The previously-posted revision specified when a command timeout occurs.
>> I now propose to implement the timeout into the state machines by stating
>> that when a timeout occurs, the device server sends a (newly-defined)
*Time
>> Out Command* message to the appropriate set of LU_CS states.  And I’ll
>> define the resulting behaviors.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Paul
>>
>>
>>
>> *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org <owner-t10 at t10.org>]
*On
>> Behalf Of *Paul Suhler
>> *Sent:* Wednesday, May 28, 2014 4:01 PM
>> *To:* T10 E-mail Reflector (t10 at t10.org)
>> *Subject:* SAM-5 Command Timeout Subproposal for 14-107
>>
>>
>>
>> Hi, George (and anyone else who wishes to comment).
>>
>>
>>
>> As suggested in CAP in May, I’m trying to leverage the new state
machines
>> in 14-054 for defining the command deadline operations.  For example, in
>> order to record the arrival time of a command and set its expiration time,
>> I want to abandon adding an argument to the Route Command operation and
>> instead hang it on a newly-defined transition.  Using 14-054r3 as a base,
I
>> propose to add the paragraph in blue:
>>
>>
>>
>> *8.9.4.2 LU_CS1:Idle state*
>>
>>
>>
>> *8.9.4.2.1 LU_CS1:Idle state description*
>>
>>
>>
>> This is the initial state of the LU_CS state machine.
>>
>>
>>
>> *8.9.4.2.2 Transition LU_CS1:Idle to LU_CS2:Dormant*
>>
>>
>>
>> This transition shall occur after receiving:
>>
>> a) a Queue Command message with a Task Attribute argument set to Simple;
>> or
>>
>> b) a Queue Command message with a Task Attribute argument set to Ordered.
>>
>>
>>
>> This transition shall include the following arguments:
>>
>> a) I_T_L_Q Nexus;
>>
>> b) CDB;
>>
>> c) Task Attribute;
>>
>> d) CRN, if any;
>>
>> e) Command Priority, if any; and
>>
>> f) First Burst Enabled, if any.
>>
>>
>>
>> If this transition occurred after receiving a Queue Command message with
>> a Task Attribute set to simple, then the Deadline Expiration time
>> attribute of this command shall be set as specified in 8.7.2.2.
>>
>>
>>
>> The new subclause 8.7.2.2 relies upon the proposed command deadline
>> clock, which is in the logical unit, and upon a command deadline value in
>> the proposed Command Deadline mode page.
>>
>>
>>
>> Any problems with specifying this behavior here?  Other questions?
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Paul
>>
>>
>>
>> *Paul A. Suhler, PhD*
>>
>> Research Staff Member
>>
>> HGST Research
>> paul.suhler at hgst.com
>> o: 949-476-1180 x275448
>>
>> m: 949-241-6443
>>
>> 3001 Daimler St.
>> Santa Ana, CA 92705-5812
>> www.hgst.com
>>
>>
>>
>>
>>
>>
>>
>
>



More information about the T10 mailing list