SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: Data in SCSI Response or SCSI Data



    
    
    The status message is in the iSCSI header (not after the data).
    If the status is bad and/or includes sense data it should be sent
    separately.
    
    Julo
    
    "Y P Cheng" <ycheng@advansys.com> on 25/08/2000 23:23:00
    
    Please respond to "Y P Cheng" <ycheng@advansys.com>
    
    To:   "Robert Reynolds" <robertr@Crossroads.com>, ips@ece.cmu.edu
    cc:    (bcc: Julian Satran/Haifa/IBM)
    Subject:  RE: Data in SCSI Response or SCSI Data
    
    
    
    
    > From: Robert Reynolds
    >
    >  Although it's true that 99.99% of reads will be successful it is
    >  not always true that the status can be implemented with one bit.
    >  If you are doing Tape Reads using variable block records then
    >  you also need to ensure that the underrun data length is included
    >  as part of the status.
    
    No, this is not a problem.  In reading, the SCSI initiator knows how many
    bytes it has received and will report the underflow condition correctly.
    The SCSI target needs not report the transfer size.  On a write operation,
    the SCSI target always return a status message in which it stores the
    residue count, the amount of data not written.
    
    >  Another thought on why it would be a good thing to combine status
    >  and data is for congestion control.  Either the sender has to wait
    >  for more data in the window before sending the status or it is sending
    >  a lot of small TCP packets containing the status which is probably
    >  not what we would want to see on the network.  By combining the status
    >  with the last data frame you can avoid this potential problem.
    
    Yes.  However, this is how the hardware handles the bundled packets.
    
    1) the whole packet is in the receive FIFO.  2148 bytes for the FC and 1500
    for Ethernet.
    2) the media header is decoded to get the FC or Ethernet media control
    information.
    3) the IP header is decoded from which we learn if there is a iSCSI, FTP,
    or
    VI header.
    4) from the iSCSI header we direct the command and status to the microcode
    and move the data to a pre-defined receive buffer (This is where TCP/RDMA
    will be handled.)
    
    Note, at step 4, the hardware parses the packet.  Normally, the hardware
    does one thing well repeatedly.  If there is a status message tagged along
    the data message, the hardware must first perform DMA data transfer. Then,
    it repeats step 4 for the status message.  It is quite doable if we got a
    programmable sequencer in the hardware.  However, what happen if we got a
    DMA transfer error, how do we report to the microcode that besides the DMA
    transfer error, there is still a status message left in the receive FIFO?
    It gets a little more complicated.
    
    
    
    
    


Home

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