Re: opcodes

[julian_satran@il.ibm.com]

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.

Regards,
Julo

"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
>
>
>
>
>