SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: Use of the A bit



    
    If it hurts, don't do that.  Keep it within MaxBurstSize constraints.  And
    set MaxBurstSize correctly for the device.
    
    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSG San Jose Ca
    Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    Home Office (408) 997-6136, Cell: (408) 499-9702
    Internet address: hufferd@us.ibm.com
    
    
    Eddy Quicksall <Eddy_Quicksall@ivivity.com>@ece.cmu.edu on 03/13/2002
    12:02:38 PM
    
    Sent by:    owner-ips@ece.cmu.edu
    
    
    To:    "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)"
           <matthew_burbridge@hp.com>, "ips@ece. cmu. edu (E-mail)"
           <ips@ece.cmu.edu>
    cc:
    Subject:    RE: iSCSI: Use of the A bit
    
    
    
    
    Then  my only concern is that the initiator may ignore the A bit  if it
    deems that the bit is being set  aggressively.
    
    If it ignored it,  then the target would be stalled waiting for he ACK.
    
    Eddy
    -----Original Message-----
    From: BURBRIDGE,MATTHEW  (HP-UnitedKingdom,ex2)
    [mailto:matthew_burbridge@hp.com]
    Sent:  Wednesday, March 13, 2002 1:39 PM
    To: 'Eddy Quicksall'; ips@ece.  cmu. edu (E-mail)
    Subject: RE: iSCSI: Use of the A  bit
    Importance: High
    
    
    Eddy,
    
    The target is quite within its rights to use the A  bit when at recovery
    level 0.  If the session is re-established due to  recovery 7.11.4 then the
    relevant command is aborted anyway and so there is no  reason to keep hold
    of the data any way: With recovery level 0 there is  no recovery mechanism
    that requires the target to keep the data.   Therefore the A bit is
    redundant when the recovery level is  0.
    
    The spec says that the initiator MUST issue a SNACK  if the A bit is set.
    However, the MaxBurstSize restriction is there to  prevent the initiator
    from having to send a SNACK on every PDU in the case  where a target
    inadvertently sets the A bit in (for example) every data in  PDU. The
    target may set the A bit more often than the MaxBurstSize but it  should
    not expect a SNACK more often than this.
    
    Matthew Burbridge
    -----Original Message-----
    From: Eddy Quicksall  [mailto:Eddy_Quicksall@ivivity.com]
    Sent: Wednesday, March 13,  2002 3:12 PM
    To: ips@ece. cmu. edu (E-mail)
    Subject:  iSCSI: Use of the A bit
    
    
    Here is a case  that I want to go over and if there is not already a
    solution, I think a  refinement to the A bit could solve it.
    
    The problem is  that a target (perhaps an iSCSI disk drive) does not have
    enough memory to  transfer the full READ request so it must read from the
    medium as much  as it can, transmit that, when that transmission is known
    to be good, read  the next bunch, transmit that and so on.
    
    The problem we  have is that the target must keep the buffer around until
    the transfer has  been "ack'd" via ExpStatSN. But that status can't be sent
    because all of the  requested data has not been sent. So the target would
    have to refuse to do  the command.
    
    I was going to  use the A bit for this thinking it would force the
    initiator to give an  "ack" but our current wording does not make this a
    sure fire  thing:
    
    1) The initiator  may not want to run at ErrorRecoveryLevel 1.
    2) The initiator  may ignore the A bit if it deems that the bit is being
    set  aggressively.
    3) The target  may set the A bit no more frequently than MaxBurstSize.
    
    Comments?
    
    
    mailto:Eddy_Quicksall@iVivity.com
    
    
    
    
    
    


Home

Last updated: Thu Mar 14 10:18:16 2002
9118 messages in chronological order