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

Gerry Houlder gerry.houlder at seagate.com
Fri May 30 10:42:52 PDT 2014


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

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