Command Deadlines: HP's Modest Proposal
Ballard, Curtis C (HP Storage)
curtis.ballard at hp.com
Thu Sep 4 09:29:23 PDT 2014
Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1409041_f.htm">HTML-formatted message</a>
âper opcodeâ isnât defined. The simple path would be to say each
opcode/service_action pair but we could define a mapping so a single timeout
value maps to all READ commands regardless of size.
The mode page policy is an issue but which is more difficult, dealing with a
per I_T nexus mode page or getting the priority through the storage stack?
There are use models where a shared mode page would still work but it would
be quite a bit less flexible. In at least one use case weâre considering
there would only ever be one initiator so the mode page policy really
wouldnât matter. I donât think the question of what values to use when a
new initiator first makes itself known is a problem in this case, a new
initiator wouldnât have any timeout values set until it established them.
I think we would have to define the model for a device server running out of
command timeout slots. The model could allow for the device server to have a
pool of timeouts that is shared across all initiators and timeouts are
assigned to specific initiators following a MODE SELECT specifying timeouts,
then whenever that pool is expired attempts to set a new timeout would error
with a well-defined response.
The current proposal has the mode page policy as âshouldâ be per I_T
nexus but does allow for shared.
Curtis Ballard
Hewlett-Packard Company
+1 970 898 3013 / Tel
Curtis.Ballard at hp.com / Email
Fort Collins, CO
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Gerry Houlder
Sent: Thursday, September 4, 2014 10:02 AM
To: T10 Reflector
Subject: Re: Command Deadlines: HP's Modest Proposal
So when you say "per op code", this means one value for READ(10), one for
READ(16), and one for READ(32)? And three more for the comparable write
commands? And a requirement to save a separate copy of this new mode page
(that contains 6 timeout values) for every initiator? How many initiators
would you expect a target device to handle? Most target devices use shared
mode page policy for all mode pages to avoid that last issue -- a separate
mode page for each initiator brings a lot of questions, such as what values
to use when a new initiator first makes itself known and what to do when the
target has reached its limit of the number of initiators it can handle.
i would prefer an implementation that works OK when the mode page is shared
across all initiators.
On Wed, Sep 3, 2014 at 7:15 PM, Ballard, Curtis C (HP Storage)
<curtis.ballard at hp.com> wrote:
The total number of timeout values shouldnât need to be any more than the
current proposal which defines 30 timeout values per I_T nexus. The device
server could define a set of commands where timers are supported and could
have a maximum number of timers. Instead of timers being associated with a
priority they would be associated with specific commands. Most applications
will have a small set of commands where they want to use deadlines.
As we discussed in the last conference call, these timeout values donât
have to map to timers. The model is taking the command arrival time and
adding the timeout to generate a command deadline and the device server
checks the current time against the deadline rather than running a timer.
This model doesnât provide as much flexibility for the application as being
able to pick from a table of timers for every command but can work with the
existing CDBâs without needing to use the transport specific command
priority. If more flexibility is needed 2 bits in the control byte could
allow selecting from one of 4 timeout values.
Curtis Ballard
Hewlett-Packard
From: owner-t10 at t10.org<mailto:owner-t10 at t10.org> [mailto:owner-t10 at t10.org]
On Behalf Of George Penokie
Sent: Wednesday, September 3, 2014 4:19 PM
To: Paul Suhler
Cc: T10 E-mail Reflector (t10 at t10.org<mailto:t10 at t10.org>)
Subject: Re: Command Deadlines: HP's Modest Proposal
:Paul,
One timeout per opcode per I_T_L nexus sounds like one heck of a lot of
timers to me.
Bye for now,
George Penokie
Avago Technologies
Attn: George Penokie
4109 Manor View Dr NW
Rochester , MN 55901
507-328-9017
george.penokie at avagotech.com
On Wed, Sep 3, 2014 at 4:30 PM, Paul Suhler
<Paul.Suhler at hgst.com> wrote:
Hi, all.
Curtis Ballard has made an interesting suggestion for a major change to last
weekâs T10/14-107r2:
Instead of providing two sets of fifteen timeouts, one timeout would be
provided per-opcode-per-I_T_L nexus. That timeout would be used if a
newly-allocated bit in the CDBâs Control byte were set.
Advantage:
No need to wait for the Command Priority attribute to be added to transport
implementations and to driver stacks, which could take years.
Disadvantage:
In cases where an initiator wants to change the timeout for a particular
command (e.g., READ(16)) on a particular LU, it would have to send a MODE
SELECT.
Questions:
1) Does anyone feel that one timeout per opcode per I_T_L nexus is too
much of a constraint? HP doesnât.
2) Does anyone object to using mode pages, with the requirement that the
data length on MODE SELECT must match the data length on MODE SENSE? (The
alternative is yet another command.)
Thanks for your feedback,
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/>">http://www.hgst.com/>
More information about the T10
mailing list