RE: iSCSI: StatSN Field in R2T messages.

["Gwendal Grignou" <ggrignou@silverbacksystems.com>]

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