SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI Plugfest at UNH



    > > +++ Should we really? A good driver will do what it can to optimize its use
    > > of resources while getting maximum performance. IMHO a warning to
    > > implementers will be enough and I will try to put it in.++++
    
    Julian,
    
    Matthew Burnbridge explained this well at the plugfest meeting.
    
    The problem is that the target does not know if its dealing
    with a good initiator or a bad one.   The protocol is introducing
    needless network delay (wait states!).
    
    Why wait for the final bit if the target has enough memory to 
    handle all the data right away (and could send R2Ts *NOW*) ?   
    
    Regards,
    -Sandeep
    
    
    >  12.If unsolicited data is negotiated, it appears that it still does not
    >     have to be used.  In practice this can lead to performance
    > inefficiencies.
    > 
    >     Consider the following:
    >         - Unsolicited data has been negotiated to YES but immediate data
    >           is NO (although a problem still exists even if this is YES).
    > 
    >         - The initiator sends a SCSI command with F=0, W=1 and a large
    >           Expected Transfer Length field (greater than FirstBurstSize).
    > 
    >         - When the target receives this command, it knows that unsolicited
    >           data follows (because F=0), but does NOT know how much (there
    >           is a maximum determined by the negotiated FirstBurstSize, but
    > there
    >           is no requirement that the initiator actually send this much).
    >           Therefore, the target cannot at this time send out an R2T to get
    >           the "rest" of the data --  it must wait to receive data PDUs
    >           until it gets the F=1 set on one of these data PDUs, and then
    >           compute the amount of data to ask for in the R2T.  This may
    >           introduce needless delay.
    > 
    >           To avoid this situation, the standard should either:
    >           - require that when unsolicited data is to be sent, that the
    >             amount be min(Expected Transfer Length, FirstBurstSize),
    >           - alternatively, provide a field in the SCSI command that
    >             allows the initiator to indicate how much unsolicited data
    >             follows.
    > 
    > > +++ Should we really? A good driver will do what it can to optimize its use
    > > of resources while getting maximum performance. IMHO a warning to
    > > implementers will be enough and I will try to put it in.++++
    


Home

Last updated: Tue Sep 04 01:04:16 2001
6315 messages in chronological order