Re: MaxBurstSize ambiguous and should be separated

["Mallikarjun C." <cbm@rose.hp.com>]

John and Julian,

A couple of comments.

> devices, that have more buffers for input then they have for output

I think the issue is that the input buffer limit of the target which 
generally decides MaxBurstSize doesn't have to constrain the 
read data sequence size if the initiator is willing to receive more in
a sequence (generally limitless).  OTOH, there are two (arguably minority)
cases where the targets can't generate very long read data sequences 
even after the proposed change - 
    a) when the initiator wants the read sequence to end sooner, possibly 
        to start the outbound data transfer in the case of bidi commands. It
        may however be larger than target's buffer  limit.
    b)when the A-bit is used, the target can not really pipeline the data 
        into one long sequence, since it must keep the data until it's ack'ed and 
        the same buffer restrictions apply that it has for inbound data (John's
        argument).

My question really is: what is being gained in longer sequences?  IOW,
how is one 4K burst with one F-bit more efficient than one 4K burst with 
two F-bits?

At least, I am not clear on the answer to this question.  Changing obviously
has some downsides besides that it's not a must-fix issue - the A-bit text
would need to be changed (again), and there may be other text that needs to 
be revised that currently depends on MaxBurstSize (for ex. MaxRecvPDULength)...

Comment on Ron's original question -
> MaxBurstSize, as it is now defined, limits both write sequences (by
> limiting
> the R2T) and limits read sequences supposedly when using the A bit.

The implication in this sentence isn't quite correct.  The text only says that
the A-bit must not be set more frequently than MaxBurstSize, it doesn't
say anything in regards to the association of *A-bit* to the sequence size.  
MaxBurstSize generally mandates the setting of the *F-bit* (even though 
this isn't quite obvious today), not the setting of the A-bit (A-bit doesn't have 
to be used at all!).
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com

----- Original Message ----- 
From: "John Hufferd" <hufferd@us.ibm.com>
To: "Julian Satran" <Julian_Satran@il.ibm.com>
Cc: "Ron Grinfeld" <Rong@siliquent.com>; <ips@ece.cmu.edu>
Sent: Monday, March 18, 2002 8:49 AM
Subject: Re: MaxBurstSize ambiguous and should be separated


> 
> Before, we do this,  I think we need to understand if there really are
> devices, that have more buffers for input then they have for output, or
> visa versa.  It would seem that we remove simplicity that applies to 99% of
> the devices, for some imagined flexibility.
> 
> I see no need for this change.
> 
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Home Office (408) 997-6136, Cell: (408) 499-9702
> Internet address: hufferd@us.ibm.com
> 
> 
> "Julian Satran" <Julian_Satran@il.ibm.com>@ece.cmu.edu on 03/18/2002
> 04:45:51 AM
> 
> Sent by:    owner-ips@ece.cmu.edu
> 
> 
> To:    Ron Grinfeld <Rong@siliquent.com>
> cc:    ips@ece.cmu.edu
> Subject:    Re: MaxBurstSize ambiguous and should be separated
> 
> 
> 
> 
> Ron,
> 
> Arguments can be brought for having single limit such as:
> 
>    simplicity
>    it is a SCSI-to-SCSI limit and most devices are using one direction at a
>    time
> 
> However it is a simple matter to make 2 limits as for the transport so we
> may want to do it if there are no good technical arguments against it.
> 
> Julo
> 
> 
> 
> 
>                       Ron Grinfeld
>                       <Rong@siliquent.c        To:       Julian
>                       Satran/Haifa/IBM@IBMIL
>                       om>                      cc:
>                                                Subject:  MaxBurstSize
>                       ambiguous and should be separated
>                       17-03-02 15:25
>                       Please respond to
>                       Ron Grinfeld
> 
> 
> 
> 
> 
> Julian,
> 
> MaxBurstSize, as it is now defined, limits both write sequences (by
> limiting
> the R2T) and limits read sequences supposedly when using the A bit.
> Furthermore, according to section 11.13, it limits ANY data-in sequence
> (without mentioning error recovery or A bit usage). Therefore it is both:
> 
> (1) Ambiguous - is it or is not applicable to data-ins when A bit is NOT
> used?
> (2) Needlessly confining - why should data-in and data-out sequence limits
> be artificially tied through this one parameter
> 
> Why don't we define instead:
> 
> (a) MaxDataOutBurstSize (max sequence of data-outs - limits R2Ts)
> (b) MaxDataInBurstSize  (max sequence of data-ins, point of ACK or
> direction
> change)
> 
> Rong
> 
> 
> 
> 
> 
> 
> 
>