SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iSCSI: FirstBurstSize and unsolicited data



    While there is no need to reduce FirstBurstSize to MaxRecvDataSegmentLength (current name for MaxRecvPDULength below), 11.15 says:
    
    "FirstBurstSize MUST NOT exceed MaxBurstSize."
    
    and it doesn't moderate that with a statement such as "unless InitialR2T=yes" so it would probably be wise to reduce FirstBurstSize if needed to satisfy that condition in case your partner checks the relative values of the parameters even when FirstBurstSize isn't important.
    
    Regards,
    Pat
    
    -----Original Message-----
    From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com]
    Sent: Friday, June 14, 2002 1:43 PM
    To: Bill Studenmund; Nandakumar Ramamurthy
    Cc: ips@ece.cmu.edu
    Subject: RE: iSCSI: FirstBurstSize and unsolicited data
    
    
    The initiator should probably reduce FirstBurstSize to 8k.
    
    Although the spec does not seem to mandate this.
    
    
    Eddy
    
    -----Original Message-----
    From: Bill Studenmund [mailto:wrstuden@wasabisystems.com]
    Sent: Friday, June 14, 2002 1:22 PM
    To: Nandakumar Ramamurthy
    Cc: ips@ece.cmu.edu
    Subject: Re: iSCSI: FirstBurstSize and unsolicited data
    
    
    On Fri, 14 Jun 2002, Nandakumar Ramamurthy wrote:
    
    > Hi All,
    >
    > Consider the case where InitialR2T=yes and ImmediateData=yes.
    > All other values are the defaults.
    >
    > The expected data transfer length for a SCSI write
    > operation is a value exceeding FirstBurstSize (64KB).
    >
    > In the above case, the initiator will send immediate
    > unsolicited data (MaxRecvPDULength=8192 bytes).
    > After that it has to wait for an R2T from the target.
    
    That is correct.
    
    > In this scenario, FirstBurstSize of data will not be sent
    > to the target as unsolicited data-out's cannot be sent here.
    >
    > My understanding is that the remaining data can be
    > sent only through solicited Data-out PDUs,
    > and this is the expected way according to the draft.
    >
    > What does the following statement(in Section 9.4.6.2 Sense Data) mean in
    > this context ?
    >
    > <quote>
    >
    > The target reports the "Not enough unsolicited data" condition only
    > if it does not support output (write) operations in which the total
    > data length is greater than FirstBurstSize, but the initiator sent
    > less than FirstBurstSize amount of unsolicited data, and out-of-order
    > R2Ts cannot be used.
    >
    > </quote>
    
    I think what that's getting at is if you do a write command and send
    unsolicited data-out PDUs, you've promised to send FirstBurstSize worth of
    data. If you don't, to continue the operation, the target needs to send an
    R2T for the missing data. But that would be an out-of-order R2T since by
    sending unsolicited data, you are acting as if you received an R2T for
    FirstBurstSize data; this error R2T would be going backwards.
    
    Take care,
    
    Bill
    


Home

Last updated: Thu Jun 20 13:18:49 2002
10910 messages in chronological order