RE: iSCSI: CmdSN and Retry

["Douglas Otis" <dotis@sanlight.net>]

Santosh,

TCP mandates sequential delivery.  As was often stated on this reflector,
framing would be to place data payloads but would not impact the sequence of
any operation.  An extra handshake that requires a small delay should there
be a non-sequential event would occur orders of magnitude less often than
similar waits for TCP.  As this must be a rare event, the wait will be
insignificant.  Assurance of sequential delivery improves reliability and
does not require command-by-command pacing to provide expected SCSI
operation that otherwise is easily done with parallel SCSI configurations.
The buffer size will be nominally one packet larger to handle such extra
handshake and again insignificant.  I see nothing to justify complexity
offered by convoluted recovery for a digest error.  SCTP offers a means of
delivering objects out-of-sequence and then perhaps flagging which objects
can violate SCSI's sense of ordering could be done to help facilitate long
pipes.  If this ever becomes a significant factor, the bandwidth will be so
small as to be of little concern anyway.

Doug

> > Unless the transport maintains order, there will be a
> requirement to wait
> > for each command to complete to assure the sequence.
>
> Doug,
>
> The majority of SCSI stacks today DO function as stated above.
> The layer above ULP enforces the ordering and awaits completion of 1 I/O
> prior to posting the subsequent I/O , PROVIDED those 2 I/Os required
> ordering to be maintained.
>
> > This makes
> > compliance to SCSI impossible and not a means of improving the
> pipe-line.
> Are you saying that the majority of stacks today are not
> SCSI compliant (?)
>
> YP raises a valid concern in that if strict ordering is expected from the
> transport, it should be capable of providing this 100 %. (98% strict
> ordering is'nt good enough.). To attempt to provide 100% guarantee of
> strict ordering is going to prevent concurrent I/O processing at the
> target at a session level (NOT even a LUN level, which is the granularity
> where one would expect ordering, if at all !).
>
> Regards,
> Santosh
>
>
>
> --
> #################################
> Santosh Rao
> Software Design Engineer,
> HP, Cupertino.
> email : santoshr@cup.hp.com
> Phone : 408-447-3751
> #################################
>