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

Paul Suhler Paul.Suhler at hgst.com
Mon Jun 2 10:16:45 PDT 2014


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

Thanks for the advice, George.	Two comments:
First, my only worry about supporting deadlines for ORDERED is a statement in
SAM-5 8.7, “If the command has a task attribute other than SIMPLE, then
command priority is not used.”  Nowhere in SAM-5, SPL-3, FCP-4  does it say
that the Command Priority argument *can’t* be set in Send SCSI Command,
etc. when the Task Attribute is SIMPLE, but implementers might interpret it
that way, leaving no way to look up the deadline value, which is hooked to
the priority.  Not a show-stopper, but clarification may be needed.
The other comment is that timer expiration isn’t the only trigger for
abandoning a command, e.g.,
a)	A cheap device server that doesn’t implement a timer mechanism to
halt a Dormant command and just waits for the first data transfer to check
the clock.
b)	A sophisticated device server that can estimate that a command
won’t become enabled before the deadline and abandons it without waiting.
I plan on posting a revision before tomorrow’s call, on the off-chance we
have time to discuss it.
Cheers,
Paul
From: George Penokie [mailto:george.penokie at avagotech.com]
Sent: Monday, June 2, 2014 8:49 AM
To: Gerry Houlder
Cc: Paul Suhler; T10 Reflector
Subject: Re: Yet Another SAM-5 Command Timeout Subproposal for 14-107
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>
[mailto: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>
[mailto: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<mailto: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> [mailto: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<mailto: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<tel:949-476-1180%20x275448>
m: 949-241-6443<tel:949-241-6443>
3001 Daimler St.
Santa Ana, CA 92705-5812
www.hgst.com<<a href="http://www.hgst.com/&gt">http://www.hgst.com/&gt;



More information about the T10 mailing list