SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: Status summary on multiple connections



    
    
    David,
    
    I think that RDMA out-of-order processing is important only in order not to
    have data
    piling up in adapters. It does not mean that data gets really "committed".
    The commands can be executed in or out-of-order - this is a pure SCSI
    story.
    But if they have to be executed in order the ordering provided by SCSI
    will enable it.
    And as you and others have pointed out the same mechanism is good for both
    ordering and flow control.
    As far as I understand it windowing - although more expensive - is a better
    technique over a wide variety of latencies than credits.
    
    And BTW we even considered credits for a "prefetching mechanism" for
    chained
    commands but where told that those are very much "out of fashion" (i.e. not
    worth speeding up on Elefants).
    
    Julo
    
    
    
    David Robinson <David.Robinson@EBay.Sun.COM> on 29/09/2000 21:25:52
    
    Please respond to David Robinson <David.Robinson@EBay.Sun.COM>
    
    To:   ips@ece.cmu.edu
    cc:    (bcc: Julian Satran/Haifa/IBM)
    Subject:  RE: Status summary on multiple connections
    
    
    
    
    > I am left with the following impression as to what was indicated here:
    > - In general, command ordering is not relevant
    > - If the initiator filesystem detects an ordering dependency, it will
    wait
    > until outstanding commands are complete before issuing the dependant
    > command.
    >
    > This may be a reasonable means of operation for the disk world. It is
    > woefully inadequate for the tape world, as follows:
    > - In general, command ordering is crucial - out of order command
    processing
    > will lead to data corruption.
    > - This would require the initiator backup application to block on
    completion
    > of every single write command of a backup operation before issuing the
    next
    > command.
    >
    > If this blocking were performed, both the throughput and capacity of a
    tape
    > device/media would be negatively impacted by an order of magnitude or
    more.
    > This would occur even assuming an instantaneous transport.
    
    I am hearing different stories on the issue of ordering.  One side
    is pushing hard for techniques that will allow out of order
    execution using various RDMA techniques. This clearly states for
    a certain class of devices (e.g. tapes) ordering is crucial.
    I thought this problem was already solved at the SCSI layer
    through the use of ordered commands which in general are not used
    for disks but always used for tapes?  Since FC will reorder this
    has to be a solved problem. Would not an initiator talking to
    a tape target simply set the ordering flag?
    
    Lastly, for a TCP based connection ordering can easily be made a
    non-issue, simply don't try to process segments out of order.  I
    will defer to a transport expert, but I believe processing
    TCP segments by an application out of order might cause problems.
    In particular since the out of order segment is not ACKed until
    after the missing segments arrive, they can be retransmitted
    multiple times.  SACK helps this but does not guarentee that
    segments will not be retransmitted. So to process out of order
    segments the application must maintain a list of which segments
    have been processed as well, yuck!
    
         -David
    
    
    
    
    
    


Home

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