RE: sector alignment for DataOut PDUs?

["Martin, Nick" <Nick.Martin@compaq.com>]

Martins,

Comments imbedded.

> -----Original Message-----
> From: Martins Krikis [mailto:mkrikis@yahoo.com]
> Sent: Thursday, February 28, 2002 2:02 PM
> To: ips@ece.cmu.edu
> Subject: RE: sector alignment for DataOut PDUs?
> 
> 
> I like the DataPDUAlignment parameter.
> (Just mandating to send maximum amount of data
> that's allowed, while being a good thing,
> still cannot guarantee the right alignment
> if those limits are not the right multiples.)
> 
> But I don't see why the selection function should be
> the minimum of two numbers. That way the outcome may
> be completely inapropriate for the target. 
> I think that whatever the target declares should be
> the final value. So the selection function should
> be called, IMHO, "target said so".
+++
Yes, I see your point.
+++
> 
> Also, (I'm quoting Nick):
> > When DataPDUAlignment is non-zero, 
> > for any PDU other than the last in a
> > sequence, the PDU data segment length
> > (DataSegmentLength) is required to
> >  be an integer multiple of DataPDUAlignment
> > less than or equal to MaxRecvPDULength.
> 
> In case of Data_out pdu-s even the last one should
> be aligned, shouldn't it? Since all PDU-s have
> brought data aligned on block-size, if the last
> one does the same, we guarantee that the total
> data transfer length is a multiple of block-size,
> which certainly must be so, right? So far I don't
> see a guarantee that it will be, but I feel it
> must match the length carried by CDB which is
> expressed as the number of blocks...
+++
For disks, yes this will be true.  For devices accepting variable length
records such as tape, there is no restriction on the total size.  My
intention is that only the last buffer required by the transfer would
not be an integer multiple.

I now picture a slightly more general case where the DataPDUAlignment
value requested represents the buffer memory management granularity of
the target.  This might be a convenient multiple of sector size other
than one.  Again in this case, only the final transfer would not fill
each DataPDUAlignment sized buffer allocated to receive it.

Finally, it has been suggested (by Eddy Quicksall) that allowing any
value including 1, but not zero eliminates special case processing for
0.  The value 1 means one byte alignment which is no restriction.  Any
value convenient to the target could be selected, or the target can
leave it unspecified which means it does not require alignment.
+++
> 
> Finally, speaking about MaxRecvPDULength, this
> really is the last of operational parameters that
> is not negotiated, but instead declared, right? That
> makes it different from others. Plus, the same key
> means different things depending on which direction
> it is sent. While I'm not as upset with this as I
> was about RFMarkInt, wouldn't it look cleaner if
> we used two different keys, MaxORecvPDULength and
> MaxIRecvPDULength? We could even say that they
> are negotiated with the very special selection
> functions "initiator said so" and "target said so",
> respectively...
> 
> Any comments?
> 
>   Martins Krikis, Intel Corp.
> 
> Disclaimer: These opinions are my own and may not
>             reflect those of my employer.
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Greetings - Send FREE e-cards for every occasion!
> http://greetings.yahoo.com
>