Subject: Re: iSCSI: ERL=1 question.

From: "Prasenjit Sarkar" <[email-masked]>
Date: Thu, 3 Jan 2002 18:03:59 -0800

I'm assuming Santosh wanted to reply to the entire group, so I am
forwarding his response to the mailing list.

Santosh's argument is to provide the (unstated) rule that data assembly is
the domain of a lower iSCSI layer whose job is to filter out duplicate SCSI
status PDUs. I would gladly accept this argument except that a standard
should present a generic rule which should be independent of how a protocol
is implemented. I would prefer a rule based on stat_sn ordering or any
other equivalent rather than one based on ideal iSCSI layering.

Santosh's motivation of having a seamless way of completing commands is
probably not true as initiators are allowed to generate SCSI responses.

   Prasenjit Sarkar
   Research Staff Member
   IBM Almaden Research
   San Jose

                    Santosh Rao                                                                                                               
                    <santoshr@cup.       To:     Prasenjit Sarkar/Almaden/IBM@IBMUS                                                           
                    hp.com>              cc:                                                                                                  
                    Sent by:             Subject:     Re: iSCSI: ERL=1 question.                                                              
                    [email-masked]                                                                                                            
                    p.com                                                                                                                     

                    01/03/2002                                                                                                                
                    05:00 PM                                                                                                                  

Prasenjit,

Responses inline.

Regards,
Santosh

Prasenjit Sarkar wrote:
>
> Assume the following scenario where I and T stand for initiator and
target
> respectively.
>
> 1. I->T: Scsi Cmd
>
> 2. T->I: Scsi Data (DataSN:0)
>
> 3. T->I: Scsi Status (Good)
>
> Assume there is a data digest problem for the data with DataSN:0, so
>
> 4. I->T: Data Snack for DataSN:0
>
> The target for some reason cannot respond with the data, so according to
> the spec
>
> 5: T->I: Reject with reason DATA_SNACK_REJECT
>
> 6. T->I: Scsi Status (iSCSI response: SNACK rejected -> SCSI READ Error)
>
> The questions are as follows:
>
> A. Is SAM ambivalent of the fact that there can be two statii for the
same
> command? (I dont have a problem if SAM doesnt)

I'm not certain on what SAM says on this one. However, one can envision
that the iscsi i/o finite state machine would enter into some state upon
encountering a datasn hole, say, data_snack_sent, and it should ignore
any scsi status received while in this state.
The lower pdu receive and re-assembly module should have passed format
and digest checks (assuming the frame came thru fine) and so, the local
value of exp_statsn should have gotten updated within this initiator
instance's iscsi connection finite state machine.

Thus.....
i) since the 1st status was ignored while awaiting a data_snack
response, only 1 scsi status ends up being processed by the i/o finite
state m/c.

ii) there will not be a statsn hole, since the previous status was
received successfully by the receive path, resulting in an update to
exp_statsn. however, the staus was discarded within the i/o fsm.

>
> B, Does the second SCSI status have the same StatSN as the first? Likely,
> it does not, but it should be clearly stated that a SCSI status with
higher
> stat_sn overrides one with the lower stat_sn.

See above.

>
> C. I'm looking for motivation here: why does the target (rather than the
> initiator) generate the second status? Couldnt the initiator also do the
> same on receiving the DATA_SNACK_REJECT?

So that all I/Os receive a single method of completion via the SCSI
status, I guess.

--
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : [email-masked]
Phone : 408-447-3751
##################################

---

From: Santosh Rao <[email-masked]>
Date: Thu, 03 Jan 2002 18:45:46 -0800

Prasenjit,

Regarding your question (B)....

Anytime the initiator's receive path successfully receives a pdu and
passes format and digest error tests, the local state information of
exp_cmdsn, max_cmdsn, statsn should be updated based on the values that
are carried in that pdu and the rules specified in Section 2.2.2.

Thus, in your below context, when the first scsi status pdu was
received, the exp_statsn should have gotten updated and there should not
have been any hole in statsn sequence. What am I missing (?) 

Regarding your question (A)...

You may have read more into my answer than was intended. 

It is not the job of the lower layered pdu assembly path to filter out
duplicate scsi status pdu's. Rather, this intelligence would lie within
the module (finite state machine) that implemented the i/o path logic.

While a data_snack has been sent and the i/o state machine is awaiting
missing data pdu's , any received scsi status for that exchange must not
be sent up to the SCSI ULP. Upon successful receipt of all the missing
data pdu[s], the status can then be conveyed to the ULP. 

(I don't have a strong opinion either way, if we should have to state
the above in the draft, or leave it unsaid as implementation specifics.
I guess, at some point we cross over into the realm of an implementation
guide vs a protocol specification :) 

- Santosh