RE: iSCSI: Out of order commands

["Somesh Gupta" <somesh_gupta@silverbacksystems.com>]

Comments below

> -----Original Message-----
> From: Robert D. Russell [mailto:rdr@mars.iol.unh.edu]
> Sent: Thursday, November 08, 2001 11:46 AM
> To: Somesh Gupta
> Cc: Julian Satran; ips@ece.cmu.edu
> Subject: RE: iSCSI: Out of order commands
> 
> 
> 
> Somesh:
> 
> > > It seems to me that if a target can only handle x new commands,
> > > then its queueing capacity is x, and in the SCSI Response PDU it
> > > should set MaxCmdSN = (ExpCmdSn + x - 1), in accordance with the
> > > formula in section 2.2.2.1.  This in turn controls the number of
> > > commands the initiator can send, and thus prevents the incoming
> > > commands from overfilling the target's queue.
> > 
> >   This is actually a weakness of the multiple connections over
> >   multiple adapters model (it is not related to ordering).
> >   The target advertises a command window on a session wide basis.
> >   At the same time, it has to provide the resource to the adapter
> >   to be able to DMA those commands to. Since there is no restriction
> >   on which connection the commands may be received, either the
> >   target has to allocate the max resources needed to each adapter
> >   (thus committing n times the resources actually required), or
> >   has to "lie" (it would not be a complete lie) which could
> >   result in running out of resources. One way to fix that would be
> >   to have the credit on a per connection basis.
> 
> If I understand you correctly, you are saying that deadlock can
> occur even if we enforce ordered delivery by initiators and even
> if the advertisements are correct and even if both parties obey
> the advertisements.

  I would let Julian enlighten us on that, or whether it just
  leads to wholesale command drops and retries, or TASK SET FULL
  is returned (is TASK SET FULL a valid response in this case
  for a LINKED task when it is not the first command?)

> 
> In other words, doesn't this mean that the standard can lead to a
> trap in implementing targets and that, in fact, the advertisements
> really should be on a per connection basis?
> However, what would be the consequences for initiators if
> the advertisements were on a per-connection basis?

  There is really no issue with adveritisement on a per
  connection basis. It leads to a protocol change. However, it
  also allows a much more performant flow of commands.

> 
> 
> Thanks,
> 
> Bob Russell
> InterOperability Lab
> University of New Hampshire
> rdr@iol.unh.edu
> 603-862-3774
> 
> 
>