Command Deadlines: HP's Modest Proposal

Gerry Houlder gerry.houlder at seagate.com
Thu Sep 4 09:02:01 PDT 2014


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

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 <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)
> *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
>
> m: 949-241-6443
>
> 3001 Daimler St.
> Santa Ana, CA 92705-5812
> www.hgst.com
>
>
>
>
>



More information about the T10 mailing list