RE: Re: multiple connections

[Robert Snively <rsnively@Brocade.COM>]

>  -----Original Message-----
>  From: somesh_gupta@hp.com [mailto:somesh_gupta@hp.com]
>  Sent: Wednesday, September 06, 2000 5:12 PM
>  To: ips@ece.cmu.edu; matt_wakeley@agilent.com
>  Subject: RE: Re: multiple connections
>  
     snip
>  
>  2. WRITES - This is the really bad one in my opinion. For 
>  me, avoiding
>  RTTs in iSCSI would just by itself make iSCSI a superior "transport"
>  for SCSI. So assuming RTTs are not being used, the host 
>  would (changing
>  the posting order from READs), first post the write command to the
>  connection on which the data is to be sent, and then post the write
>  buffers to the connection which is to be used for sending data.
>  One case is where for whatever reason, the target gets the 
>  data before
>  it gets the command, and has no clue what to do with the data.
>  Let us assume that the target does get the command before it gets the
>  data. The target gets a command indicating that data being 
>  written to 
>  whatever lun and whatever location is going to arrive on some other
>  connection. First the target has taken an extra event from 
>  the adapter.
>  Then, when data arrives on another NIC (and the target gets another
>  event), the target goes through the list of outstanding WRITE
>  commands to match the command with the data and then go about the
>  business of processing the data.
>  
>  So in this case the work has increased for the initiator as well as
>  the target.


And to top it off, the target is active with a large number of
initiators on behalf of a large number of logical units for a large
number of queued commands, so there is absolutely no guarantee that
any buffer exists for the data that was received, even if the
command had been received first.

Every SCSI command execution is managed by the target for this reason among
many others.  Thus RTT has been a part of every SCSI protocol for write
operations.