cam_resid calculation

James Smart USG smart at zk3.dec.com
Wed Jul 7 13:03:52 PDT 1999


* From the T10 Reflector (t10 at symbios.com), posted by:
* James Smart USG <smart at zk3.dec.com>
*
Gerard,

I believe the general model on transfers is that they occur from "0" to "N"=
 with
no gaps
in between. The only acceptable variation being if they stop somewhere in t=
he
middle,
in which case all data from "0" to the "stop" point being fully transfered =
and
the "stop"
point to "N" being untransfered. Other variations, although possible, are
usually to
complex to support.

As such, it doesn't really matter how the chunks in between "0" to "stop/N"=
 get
sent,
in order, out of order, same data retransmit, etc as long as the basic mode=
l
above is
adhered to. If data between the "stop" point and "N" was sent and the trami=
ssion

protocol did not fully remove the effects of its transmission, then the i/o=
 must
fail with
a error condition that indicates the state of the data transfer is unknown.=


Relative to your questions:
  a) Must the SIM set cam_resid ?    absolutely
  b) What does the application client do if it is non-zero ?  Depends on th=
e
device
        (typically the device class - disk/tape/etc). As you pointed out, d=
isks
usually
       are an all or nothing entity, while tapes may use the transfer to se=
t
block
       lengths, etc. Other device classes may have other uses/interpretatio=
ns.
   c) What are the relationships between the transfer length, the current d=
ata
        pointer and the residual?
        Using the model above, is is easiest to answer the first and last:
Transfer
        length is the N number of bytes that are expected to be sent; and
Residual
        is the tail portion, between "stop" and "N" that did not get sent.
Current
        data pointer is not exported to the application client, and is simp=
ly a
        transmission specific entity used by the protocol chips to keep tra=
ck of

        where they are in the transfer. If the transmission protocol needs =
to
reset
        the position, resend on the current position, jump to a new positio=
n,
etc,
        it's all hidden from the application client. The client only sees t=
he
generic model.

-- James Smart

Gerard Roudier wrote:

> * From the T10 Reflector (t10 at symbios.com), posted by:
> * Gerard Roudier <groudier at club-internet.fr>
> *
>
> The CAM/CAM3 specifications seem to require SIMs to provide the residual
> count of an SCSI IO at completion.
>
> In usual situations, the calculation of this residual seems possible
> without too much complexity. But, in situations of a device using MODIFY
> DATA POINTER messages, such a calculation may get more complex. And if
> the residual applies to data that are not at the end of the buffer, this
> information may lose any relevance for the application client.
>
> My understanding of SPI is that the device may save, restore, change (if
> enabled for MDP) the data pointer at any time and so we can imagine lots
> of weird but compliant device behaviours that may complexify a lot the
> calculation of the residual count by the SIM.
>
> Looking into specifications that address SCSI devices, it seems that the
> 'residual' is mostly useless. In situation where it could help, as for
> stream devices when using variable length records, the actual number of
> bytes transferred can be obtained from the SENSE informations.
>
> As seen from the application client, the 'resid' is an information that
> addresses the data transferred to the device server that is returned by
> the transport layer. If we refer to SAM, this may appear as a layering
> violation, in my opinion.
>
> I apologize in advance for all my misunderstandings of the specs that are=

> very likely.
>
> My questions are:
>
> - Is the 'cam_resid' information required to be returned by SIM?
>
> - If yes, how the application client must behave when it is not zero?
>
> - What are the relationships between the transfer length, the current dat=
a
>   pointer and the residual?
>   For example, the SCSI specs does not preclude a device from restoring o=
r
>   changing the data pointer and then complete the IO. This is unlikely
>   to happen, obviously, but this must be considered, in my opinion.
>
> Thanks.
>
>         G=E9rard ROUDIER.
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at symbios.com

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com





More information about the T10 mailing list