Command Deadlines: HP's Modest Proposal

Gerry Houlder gerry.houlder at seagate.com
Thu Sep 4 14:20:21 PDT 2014


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

OK, i understand the reluctance to use the Priority field because existing
stacks can't use it. That is why the original proposal was trying to use
the group field in the CDB instead of the Priority field. A location in the
CDB also has advantages because it is not protocol dependent, allowing the
feature to potentially be used over an intervening FC protocol (for
instance).
Since you are willing to use the CONTROL field of the CDB (i have heard
similar complaints that stacks can't get to this byte either, so that is a
different issue), why not use 4 bits in that field so that 16 different
values are possible. This can use the 16 entry mode page that is described
in the current proposal. Up to now, we have been thinking that 16 values
would satisfy a bunch of different initiators especially since the
applications run by the different initiators might have similar deadline
requirements. This allows the target to have a shared mode page for all
initiators and simplifying a lot of things, compared to supporting a
separate mode page for each initiator.
On Thu, Sep 4, 2014 at 11:29 AM, Ballard, Curtis C (HP Storage) <
curtis.ballard at hp.com> wrote:
>  “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 <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
>
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.hgst.com_&d=AAMGaQ&c
=IGDlg0lD0b-nebmJJ0Kp8A&r=TxI1DC4HavpWBdSmUqvdNvSwgOklhaW328zLt5AOpPM&m=LGQXG
aZphTKJi8d6PpOs1l17I1-8bUt7RIBmjCfdzmA&s=ya2S3vh6OSl_-B9k521cbVFKPQZ2BOKOPdI3
5OYSTEU&e=>
>
>
>
>
>
>
>



More information about the T10 mailing list