Re: opcodes

["Mallikarjun C." <cbm@rose.hp.com>]

Julian,

Glad about your agreement on vendor-unique.

>Mallikarjun,
>
>I like the vendor unique idea!.  As for the retry bit I was ambivalent
>about it.
>You will have to check anyhow that the Initiator Tag is to there already so
>what is the point?
>
>I though that having the command coming back once more (on a different
>connection) is signalling restart anyhow.

To me, it appears that you're assuming a certain usage model with the
retry bit.  My interpretation of the retry bit (haven't checked the new
drafts to confirm, sorry) is that the initiator can use it for a command 
(say, CmdRN=X), till one of the two is true - a) status reception for X
is confirmed with ExpStatRN covering X, OR b) some sort of "timeout"
happens on the target end.  If this interpretation is true, a command can
be retried entirely because of problems on the initiator end.  The target
would then have no way to distinguish a retry from a fresh command since
it is upto the initiator to choose the structure of ITT.

More than anything else, I liked the convenience of the earlier opcode
format where I can test a single-bit and reject/ignore it if I don't support
retries at all.
--
Mallikarjun 


Mallikarjun Chadalapaka
M/S 5601			
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard, Roseville.
cbm@rose.hp.com


>
>"Mallikarjun C." <cbm@rose.hp.com> on 04/12/2000 21:41:05
>
>Please respond to cbm@rose.hp.com
>
>To:   ips@ece.cmu.edu
>cc:
>Subject:  Re: opcodes
>
>
>
>
>Julian,
>
>I would like to suggest that some opcodes be reserved as
>vendor-unique.  I also liked the earlier format of retry-bit
>encoded within the opcode byte better.
>--
>Mallikarjun
>
>
>Mallikarjun Chadalapaka
>M/S 5601
>Networked Storage Architecture
>Network Storage Solutions Organization
>Hewlett-Packard, Roseville.
>cbm@rose.hp.com
>
>
>>
>>JP,
>>
>>You have already a direction bit (good for stateless protocol analyzers).
>>
>>As for solicited - what is solicited except data and response?
>>
>>Julo
>>
>>Raghavendra Rao <jp.raghavendra@india.sun.com> on 04/12/2000 22:29:25
>>
>>Please respond to Raghavendra Rao <jp.raghavendra@india.sun.com>
>>
>>To:   ips@ece.cmu.edu
>>cc:
>>Subject:  Re: opcodes
>>
>>
>>
>>
>>
>>Julian,
>>
>>>
>>> -regular commands  00-0f
>>> -regular reponses 40 - 4f
>>> -one way 10-1f/50-5f
>>> etc.
>>>
>>> I am open to suggestions.
>>>
>>
>>For simplicity it would work best to have them fall in a range for easier
>>lookup, but it would also work better if each bit in the upper nibble of
>>the opcode denotes the following:
>>
>>     solicited
>>     unsolicited
>>     command
>>     response
>>
>>while the lower nibble describes the real code.
>>
>>With the above, since commands are always unsolicited, denoting them so
>>with 2 bits (unsolicited bit as well as command bit) appears a little
>>redundant. However, to fully qualify a response, we need either the
>>solicited or the unsolicited bits to be true.
>>
>>In any case, a bit layout for opcode field is desired.
>>
>>Thanks.
>>-JP
>>
>>
>>
>>
>>
>
>
>
>
>
>