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



    
    
    > -----Original Message-----
    > From: Matthew Jacob [mailto:mjacob@feral.com]
    >
    > > From: Y P Cheng
    > >
    > > Matt, I see your point in software implementation.  May be 
    > > this is a good time to introduce the concept of "Good 
    > > Status" flag bit.  In fact, 99.99% of iSCSI reads should 
    > > be completed without error.  For the normal completions, 
    > > all we need to is a flag bit in the data packet message
    > > header indicating "Everything is OK. This SCSI read is now completed
    > > normally."  If this flag bit is not set, there will be a 
    > > status packet with sense data following.  In the hardware 
    > > implementation, after transferring data packet into the 
    > > buffer, if this flag bit is set, we interrupt the microcode 
    > > which post the Request Block (RB) completion
    > > interrupt to the device driver.  If the bit is not set, the 
    > > hardware does nothing after data transfer.  The status packet 
    > > arrived later will be passed to the microcode that, in turn, 
    > > generates a proper RB completion interrupt to pass the error 
    > > information to the device driver.
    > 
    > Sounds good to me. If it makes the h/w easier- great. 
    > Although full status isn't that much extra, I could see that 
    > h/w for it would be harder.
    > 
    
      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.
    
      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.
    
       Bob
    
    <><><><><><><><><><><><><><><>
      Robert Reynolds      
      Crossroads Systems Inc.
      (512) 928-7222  (512)928-7401 (fax)
      robertr@crossroads.com
    


Home

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