RE: iSCSI: StatSN Field in R2T messages.

["Julian Satran" <Julian_Satran@il.ibm.com>]

Gwendal,

Your argument against the StatSN are related to one specific implementation.
Discovering earlier that there is a hole in the flow can be important for others.
Data-In packets will probably be handled by a piece of hardware in hard speed
implementations and that puts them in another category otherwise I would have argued
for piggybacking it there too.
In your implementation you are also free to  ignore the StatSN in R2T - it is only a hint anyhow
but it may indicate early that something is missing.

Julo

"Gwendal Grignou" <ggrignou@silverbacksystems.com> 06/27/2002 08:20 PM Please respond to "Gwendal Grignou"

To:        Julian Satran/Haifa/IBM@IBMIL         cc:        <ips@ece.cmu.edu>, <owner-ips@ece.cmu.edu>         Subject:        RE: iSCSI: StatSN Field in R2T messages.

Thank you for the answer Julian, my comments inline.

Gwendal.
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com] 
Sent: Wednesday, June 26, 2002 11:08 PM
To: Gwendal Grignou
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iSCSI: StatSN Field in R2T messages.



Gwendal, 

StatSN is just "piggybacked" on R2T - 9.8.2 says specifically it is not
advanced (R2Ts are counted with Data-In). 
It can help detect holes in the response sequence. 
---
GG: By providing StatSN in the R2T message, you just allow the initiator
to find the holes in the response sequence a little earlier. In anyway,
if there is -just- StatSN hole the command the R2T is describing is not
affected, but another command. The initiator would start its recovery
mechanism when it receives a iSCSI response and has finished processing
it, not when it is in the middle of processing a intermediate response
from the target. 
---
For Data-In as you have guessed it is used actively (and advanced)  when
S=1 and reserved otherwise. 
And yes we could have chosen to present it and not advance it when S=0
but the decision not to do so was 
to avoid having too many fields processed for a Data PDU (in the early
days we contemplated Data PDU to have nothing else than the placement
information for a Remote DMA).
---
GG: I totally agree not to send StatSN in DataIN if S=0, so to reduce in
the same way the number of field to process in the R2T message, couldn't
we mark the bytes 24 to 27 as reserved in the R2T message?

Gwendal.
---
Julo