SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: Flow Control



    >  
    >  The TCP connection can have either a command or data.  In either
    >  case reading a short fixed amount of data can determine if it is
    >  one or the other. With a single connection I can only see deadlock
    >  occuring if the initiator sends Command1, Command2, then 
    >  Data1 on a single
    >  command/data connection. With a single connection this seems like
    >  a broken initiator as doing the right thing of C1, D1, C2 shouldn't
    >  be any more expensive and it is definately safer. Well one other
    >  case can occur is if the initiator wants the target to issue an RTT
    >  and it interposes another command before the RTT is received, this
    >  too seems like a broken things to do as I don't see much 
    >  value in doing RTT
    >  on a single connection.
    >  
    >  In the multiple connection asymettric case this isn't an 
    >  issue as data
    >  is never interleved with commands.
    >  
    >  So is there a fundamental requirement that the target must handle
    >  the case of C1, C2, then D1? It seems easy to just write the iSCSI
    >  initiator to never issue such a sequence and if the target gets
    >  one return an error when C2 arrives before D1.
    >  
    
    David,
    
    This is one of the most valuable capabilities of SCSI and is very
    important to high performance behavior.  It is managed quite successfully
    in those "ugly" ways that were previously described.  Basically,
    a storage device has the option to choose among a large number of
    commands so that they will be completed in an optimum order.  This typically
    boosts raw performance of disk drives from about 90 IOs/second to well
    in excess of 200.  Even greater performance improvements can be achieved
    in storage controllers, since they have deeper caching and far more
    powerful and reliable data buffering.  I have heard numbers as high as
    100,000 IOPs/sec from a single storage controller.  If you can't do this
    well in TCP/IP iSCSI, then you do not have a SCSI solution.
    
    The problem is independent of datagram or not.  The same problem will
    show up with symmetric or asymmetric multiple connections and will 
    typically interact with the sort of out-of-band flow control and
    congestion management being proposed for iSCSI in pathological ways.
    
    FWIW, FC is really not a datagram service, but a messaging 
    service (Sequence = message) with acknowledgments as required 
    at the link level and/or the protocol level.
    
    Bob
    
    >  It again seems like we are trying to impose or solve 
    >  datagram problems
    >  in a stream world. Does parallel SCSI have this problem?
    >  
    >  	-David
    >  
    


Home

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