RE: sector alignment for DataOut PDUs?

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

Aryan,

In reply to your question "But what about those implementations which
would like to change the size after few transfers? Should they look/wait
for something in the spec/draft or try their own implementation?"

If you control both ends of the wire, you can add vendor specific X-
type of parameters to do what ever you want, but if you want to
interoperate with everyone, you need to raise your voice in support of
adding something like DataPDUAlignment to the spec.  Until it is
included, you can not prevent unaligned data transfer sizes.  (If you
have no desire to prevent such transfers, this parameter will not help
you.)

If you are for example a tape drive and you want to change the value on
the fly, then this parameter would need to be supported in text mode
negotiation during Full Feature Phase.  There are additional
implications if it can change with commands in flight.  I did not
explicitly state whether this was or was not permitted in my proposal.
I have not noticed any other parameters which explicitly can be changed
during FPP, although early on, I think that was one important reason to
have Text PDUs.

Also note that the scope of effect is a single value for the session
which includes the target and all of its LUs.  There did not seem to be
precedent for anything but Session or Connection scope.  It would
perhaps more logically have LU scope (no pun intended).

For a disk target, a single value is probably sufficient.  All sectors
on all LUs are (almost certainly) the same size.  For a multi LU tape
library, although each drive may be using a different (fixed or
variable) block size, there is perhaps still some value in specifying a
power of two PDU alignment to simplify buffer management.

If a target sets this value to its data buffer memory management
granularity, this could allow simplification or efficiency within the
target.  The granularity of target data buffer memory management is not
likely to change dynamically.  Efficiency of memory management in the
target is a main benefit.  Being to schedule device writes as each data
PDU arrives is another.  This is possible when no device block will span
PDUs.

Thanks,
Nick
> -----Original Message-----
> From: Ajit Aryan [mailto:digital_aryan@yahoo.com]
> Sent: Thursday, February 28, 2002 1:42 AM
> To: Martin, Nick
> Subject: Re: sector alignment for DataOut PDUs?
> 
> 
> Nick,
> That looks fine.
> But what about those implementations which would
> like to change the size after few transfers?
> Should they look/wait for something in the spec/draft
> or try their own implementation?
> 
> Aryan
> 
> Martin, Nick wrote:
> 
> >Paul,
> >
> >As Rod Harrison points out, MaxRecvPDULength is not negotiated, it is
> >"declared" and is likely to be different for Initiator and Target.  I
> >had missed the implication of this change which occurred at draft 09.
> >
> >I can now appreciate your earlier proposal.  
> >
> >To be fair to all targets, we should allow targets with 
> arbitrary sized
> >sectors/blocks to request the same kind of boundary 
> alignment.  Today we
> >already have a need to support 512, 1K, 2K, and 4K sectors 
> for disk, and
> >anything from 512 up to at least 64K blocks for tape (including
> >non-powers of 2 like 10K).  [Ouch, I just realized that the 
> tape block
> >size can be changed mid-session, the most likely time being after a
> >media change.  The tape folks may not be able to use of this 
> in the same
> >way, but let's not prevent them from trying.]  Further we do 
> not really
> >want iSCSI initiators (or their drivers) to have to guess or 
> issue SCSI
> >commands to learn the sector size.  The size needs to be specified by
> >the target during operational parameter negotiation if it is 
> requesting
> >sector/block aligned PDU payloads.  
> >
> >I actually do not think unaligned payloads are likely, but there is
> >nothing to prevent them.  We may simplify some target designs by
> >eliminating the requirement to support them.
> >
> >Certainly, we want to eliminate loopholes which allow compliant but
> >non-interoperable implementations.
> >
> >Please consider whether the following proposal meets all of your
> >requirements.
> >
> >Proposed addition to chapter 12 to enable requiring sector 
> aligned PDU
> >payloads:
> >
> >"
> >DataPDUAlignment
> >
> >Use: LO
> >Senders: Target and Initiator
> >Scope: SW
> >
> >DataPDUAlignment=<number-512-to-(2**24-1)>
> >
> >The default is 0.
> >
> >The initiator and target negotiate the alignment boundary on 
> which data
> >transfers may be continued to a subsequent PDU.
> >
> >The value 0 means no boundary alignment limitation is imposed on data
> >carrying PDUs.
> >
> >The minimum of two non-zero values is selected.  If one 
> value is zero,
> >then the other value is selected.
> >
> >This is intended primarily for a target to force an initiator to send
> >PDU data buffers whose boundaries match physical media 
> boundaries such
> >as disk sector size.
> >
> >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.
> >"
> >
> >Thanks,
> >Nick
> >
> >>-----Original Message-----
> >>From: Paul Koning [mailto:ni1d@arrl.net]
> >>Sent: Wednesday, February 27, 2002 12:57 PM
> >>To: Martin, Nick
> >>Cc: ips@ece.cmu.edu
> >>Subject: RE: sector alignment for DataOut PDUs?
> >>
> >>
> >>>>>>>"Nick" == Martin, Nick <Nick.Martin@COMPAQ.com> writes:
> >>>>>>>
> >> Nick> Paul, For all data carrying PDUs except the last in 
> a sequence,
> >> Nick> the sender is expected to send maximum sized PDU 
> allowed.  When
> >> Nick> the negotiated maximum is a multiple of 512, this effect is
> >> Nick> what you request.
> >>
> >> Nick> I thought this was a requirement, but I did not find 
> it as such
> >> Nick> in draft 10. ...
> >>
> >> Nick> IMHO, it makes more sense to include stronger wording
> >> Nick> encouraging maximum negotiated length transfers 
> rather than to
> >> Nick> add another parameter requiring PDU breaks on different
> >> Nick> boundaries.
> >>
> >>That sounds like a fine suggestion, if it gives the target enough
> >>power to achieve the alignment I'm looking for.  Strengthening the
> >>text you quoted is a start, but other places would have to be
> >>strengthened as well -- for example the rules on responding 
> to an R2T.
> >>
> >> Nick> If such initiator behavior may not be supported by 
> all targets,
> >> Nick> then the initiators SHOULD NOT do it.
> >>
> >>That's not sufficient.  You need "MUST NOT".  The reason: if you say
> >>"should not" then you can build a conforming initiator that cannot
> >>interoperate with a conforming target.  All correctly 
> written protocol
> >>specs have the property that conformance implies interoperability.
> >>(Unfortunately, few specs pass this test... :-( )  So a 
> target can be
> >>allowed to rely on full size PDUs only if initiators are 
> required (not
> >>merely encouraged) to send full size PDUs.
> >>
> >>       paul
> >>
> 
>