Subject: RE: sector alignment for DataOut PDUs?

From: Eddy Quicksall <[email-masked]>
Date: Thu, 28 Feb 2002 13:38:47 -0500

I think we got rid of the special case of 0 when the minimum is other than
0. I would hate to see it come back.

How about =<number-1-to-(2**24-1)> instead? Then you don't have to mention
the special case because a 1 would mean "no boundary alignment limitation".

Eddy

-----Original Message-----
From: Martin, Nick [mailto:[email-masked]]
Sent: Wednesday, February 27, 2002 8:41 PM
To: Paul Koning
Cc: [email-masked]
Subject: RE: sector alignment for DataOut PDUs?

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:[email-masked]]
> Sent: Wednesday, February 27, 2002 12:57 PM
> To: Martin, Nick
> Cc: [email-masked]
> Subject: RE: sector alignment for DataOut PDUs?
>
>
> >>>>> "Nick" == Martin, Nick <[email-masked]> 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
>
>

---

From: Martins Krikis <[email-masked]>
Date: Thu, 28 Feb 2002 12:01:50 -0800 (PST)

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".

Also, (I'm quoting Nick):
>  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...

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