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

Gerry Houlder gerry.houlder at seagate.com
Fri May 30 10:51:44 PDT 2014


Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1405302_f.htm">HTML-formatted message</a>

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