RE: Data in SCSI Response or SCSI Data

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

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Matt Wakeley
> Sent: Tuesday, September 05, 2000 11:39 PM
> To: ips@ece.cmu.edu
> Subject: Re: Data in SCSI Response or SCSI Data
>
>
> Ok, maybe I'm missing something, but as I read the latest (July
> 10) draft, I see
> this data/status thing working as follows.  I'm going to use
> psuedo code, so
> that (perhaps) everyone might understand...
>
> (Note that this whole discussion is only applicable to a target
> read operation)
>
> /* as a target... */
> if ((this is the last iSCSI data PDU to send to fullfill the SCSI
> command) and
>     (this SCSI STATUS is GOOD (except for residual counts)) then

When do you get GOOD status and residual counts on a read?  What is causing
the target to get the length wrong?

Is the residual count to be updated during each Read PDU?

Except for the MaxCmdRN, (add this to PDU 0x05 and make it valid during EOE)
there is little benefit in using the PDU 0x45 structure.  Nor can there be a
residual condition that is not an error.  I do not understand the benefit
using this Read PDU.  Mark the end of exchange to allow hole checking and
clean-up.  Both directions could benefit from end notification matched to a
tag.  In addition, at this level of transport, the initiator may detect
errors that should be relayed in some manner at the transport level.  Simply
add a CHECK or ERROR flag and EOE End of Exchange flag to PDU 0x05 together
with a MaxCmdRN if needed.

Doug

> {
>   set the "S" bit in the iSCSI DATA PDU header
>   /* setting the "S" bit explicitely defines "end of exchange" */
>   update the "iSCSI Status" field in the iSCSI DATA PDU header
>   if (there is a residual count) then
>   {
>     set the "O" or "U" bits and update the
>     "Residual Count" field of the iSCSI DATA PDU header
>   }
>   send the last iSCSI DATA PDU (completing the SCSI command)
> }
> else
> {
>   clear the "S" bit in the iSCSI DATA PDU header
>   send the iSCSI DATA PDU
>   if (the last iSCSI DATA PDU was sent)
>   {
>     create the iSCSI RESPONSE PDU
>     send it
>   }
> }
>
> Now, what exactly is the big issue that's required all this discussion?
>
> -Matt Wakeley
> Agilent Technologies
>
>
> Douglas Otis wrote:
>
> > Julo,
> >
> > After painfully understanding your status here not there
> conversation and
> > being ensured Autosense is now a fact of life, rather than
> placing status
> > within a READ PDU, perhaps you should consider simply revising the
> > definition of the flags and use a common DATA PDU.  Change the
> Status bit to
> > indicate Error Detected and perhaps add a bit to signal End of Exchange.
> > From End of Exchange you could deduce Good Status.  I see
> little benefit in
> > status presented twice or dummy status sent with partial
> exchanges.  It only
> > seems to make room for conflicts.  (The two values not
> agreeing, I, on the
> > other hand, will never agree.)  At what point would the O, and
> U flags be
> > valid?  Would this be a result of an error?  If so, perhap
> these flags could
> > be left to response PDU.
> >
> > Doug
>