Re: MaxBurstSize ambiguous and should be separated

["John Hufferd" <hufferd@us.ibm.com>]

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