iSCSI: retry

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

Julian,

Here are a couple of notes on command retry bit.  I had not
come across anything in the current draft to say this is not
true.  But I wanted to confirm the same since I haven't seen
a reponse from you on the attached mail.  Please comment.

o Command retry support is optional for a target. 

o It is legal to receive a command with the retry bit on the same
  connection as the one it was originally received on (IOW, retry 
  bit is the only indicator of the fact, retry-ness cannot be 
  deduced from other pieces of information.).

Thanks!
--
Mallikarjun 


Mallikarjun Chadalapaka
M/S 5601			
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard, Roseville.
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