Re: Value of "unlimited". Was Re: iSCSI: current UNH Plugfest

["Julian Satran" <Julian_Satran@il.ibm.com>]

0 as a stand in for "whatever" is out of version 09.
We don't see any need for it. It was originally provide for compatibility 
with the T10 docs when we had values "residing" in mode pages accessible 
by SCSI commands.

Julo




Tow Wang <Tow_Wang@adaptec.com>
Sent by: owner-ips@ece.cmu.edu
28-11-01 01:55

 
        To:     "Robert D. Russell" <rdr@io.iol.unh.edu>, ips@ece.cmu.edu
        cc: 
        Subject:        Value of "unlimited". Was Re: iSCSI: current UNH Plugfest

 

Hi all.

I fully agree with the suggestions for issue 4. If we really need to 
reserve a
value to mean "unlimited" or "infinite", could we use a value of all bits 
set to
one to indicate this? (Specifically, 0xFFFFFF or 0xFFFFFFFF would be great 
for
most 32-bit processors and above.) This would make arithmetic comparisons 
more
intuitive, IMHO.

"Robert D. Russell" wrote:

> Attached are the new issues that arose during the iSCSI plugfest
> at UNH on Wednesday 31-Oct-2001.
>
> (Note: these issues do not take into account any modifications or
> clarifications that occured in the standard due to the issues raised
> on Monday or Tuesday.)
>
> 4. Three numeric keys (MaxRecvPDULength, MaxBurstSize, FirstBurstSize)
>    now allow: "A value of 0 indicates no limit."
>
>    Is this useful?  Does it buy anything?
>
>    The difficulties implementers are having with this are:
>
>    1) It is a special case.
>    2) It causes discontinuous ranges (for example, [0,64..2**24])
>    3) It violates the min/max function normally used for the key.
>    4) There is always a limit anyway.
>
>    Consider FirstBurstSize, which can have a value that is described
>    as "<0|number-64-2**24>", and for which the minimum of the 2 numbers
>    is selected.
>
>    I one side offers 0 to mean unlimited, and the other side
>    has a limit, it will reply with that limit, say 128 Kbytes.
>    Therefore, the result is not min(0, 128K) but rather max(0, 128K).
>    The statement in the standard that "the minimum of the 2 numbers is
>    selected" is therefore wrong when one of the numbers is 0.
>
>    Furthermore, when an initiator or target receives an offer for one
>    of these keys, it cannot simply check that the offered value is
>    legal by testing it against some minimum and maximum.  It must first
>    check for 0 and then only if that check shows the value is non-zero
>    can it do the min/max range check for legality (i.e., 64-2**24).
>
>    Finally, there is always a limit. If nothing else it is the
>    limit imposed by the 24-bit DataSegmentLength field of the PDU
>    requesting the transfer.  It is useless to specify a FirstBurstSize
>    (or MaxRecvPDULength or MaxBurstSize) any bigger than that, because
>    the largest possible DataSegmentLength in any PDU that can use
>    this value is 2**24-1.
>
>    The suggestion is to just eliminate this special case of 0 and 
require
>    that the range 64-to-(2**24-1) be used instead -- it has exactly the
>    same effect in all cases, it is easier to describe in the standard
>    because it avoids all the extra words, and it is easier to code
>    because it avoids all the special cases.
>
>    NOTE: the standard should specify the limit in the ranges for
>    MaxRecvPDULength, MaxBurstSize, and FirstBurstSize as 2**24-1 instead
>    of 2**24.  The number 2**24 cannot be represented in the 24-bit
>    DataSegmentLength field and therefore can never be used.

--
Tow Wang
Adaptec Software Engineer       Telephone: 408 957 4838
Mail stop 46                               800 869 8883 x4838
691 South Milpitas Boulevard    Fax:       530 686 8023
Milpitas, California 95035      E-mail:    Tow_Wang@adaptec.com