RE: twist on iSCSI asymmetric model

["Binford, Charles" <cbinford@lsil.com>]

Title: RE: twist on iSCSI asymmetric model

See below...

Charles Binford
LSI Logic Storage Systems
(316) 636-8566

> -----Original Message-----
> From: meth@il.ibm.com [mailto:meth@il.ibm.com]
> Sent: Thursday, September 28, 2000 8:31 AM
> To: ips@ece.cmu.edu
> Subject: twist on iSCSI asymmetric model
>
[snip]
>
>
> The use of R2T is negotiated during the first login of the
> iSCSI session.
> If R2T is to be used, then the initiator may not send data
> before it is
> requested by the target. Thus there will always be buffers
> ready to accept
> the data. If the target agrees to not use R2T, then the
> target implicitly
> agrees to have some number of buffers available to receive
> data sent by the
> initiator, even if the data arrives before the command
> arrives.

I could agree with this IF we use the same rule as FCP's Write XFER_RDY Disable bit.  When this bit is set, it tells the initiator that it shall send the first burst of data after the command, but before the XFER_RDY.  The maximum size of the this first burst of data is set by a mode page.  If the I/O is larger that the first burst maximum, the initiator shall wait for an XFER_RDY for the balance of the data. 

The key here is the target KNOWS ahead of time the maximum number of buffers that will be used per command on an unsolicited basis.  This covers the latency issue with small writes.  When the initiator sends the occasional large I/O, the first burst goes as normal, then the balance comes when the target asks for it, after it has had time to allocate the additional buffer space. 

> In this
> case the initiator MUST send data in the data connections in
> the same order
> that the corresponding commands were sent. (This avoids
> deadlocks.) If the
> target runs out of buffers, then it will let data back up in
> the TCP window
> of the data connections, while it is processing the data from earlier
> commands.
>
[snip]
>
> - Kalman Meth.
>
>
>
>