Re: iSCSI: ERL=1 question.

["Prasenjit Sarkar" <psarkar@almaden.ibm.com>]

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.                                                              
                    santoshr@cup.h                                                                                                            
                    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 : santoshr@cup.hp.com
Phone : 408-447-3751
##################################