RE: ISCSI: Immediate data extending beyond a single PDU

[Robert Snively <rsnively@Brocade.COM>]

I do not see any reason to create the constraint that Pierre
suggests.  The goal is to negotiate a maximum acceptable buffer
space always available for unsolicited data up to the length Firstburst.
If the initiator chooses not to send that much data in the first
transfer for reasons of its own, it should be allowed to.  The 
performance penalty for the affected transfer is small and does not 
affect over-all throughput. 

There should be no architectural limitation demanding that the first
burst of a transfer greater than Firstburst in length is always equal
to Firstburst.  In particular, if it isn't, what are you going to do about
it, post an error?

Bob

>  julian_satran@il.ibm.com wrote:
>  
>  > Barry,
>  >
>  > I think that the current draft does not allow you to 
>  accept immediate but
>  > not unsolicited.
>  > You can either allow unsolicited (including immediate) or 
>  request always
>  > R2T.
>  >
>  > And yes - if the expected length is larger that what you sent as
>  > unsolicited (even if the unsolicited was less than the 
>  limit) the target is
>  > supposed to send R2T (there is only one unsolicited burst 
>  per command).
>  
Pierre Labat replied:
>  
>  I think there is a problem, as stated Barry, if the 
>  initiator decides to
>  send unsolicited data but less than the Firstburst and
>  the expected length is greater than the Firstburst. In this 
>  case the initiator
>  
>  after sending some unsolicited data waits for an R2T to continue
>  and the target waits for a First burst load of data before sending
>  an R2T.
>  
>  Solution
>  ======
>  To avoid that, it should be explicitely stated (may be it's what
>  is assumed but i can't read it) that when the initiator sends
>  unsolicited non immediate data, it must send unsolicited data
>  up to Firstburst or Expected data length whichever is less.
>  
>  Regards,
>  
>  Pierre
>  
>  <stuff deleted>
>  
>  
>