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



    That is correct but the race is not there :-) Julo
    
    
                                                                                                             
                          "Rod Harrison"                                                                     
                          <rod.harrison@win        To:       "Eddy Quicksall" <Eddy_Quicksall@ivivity.com>,  
                          driver.com>               "Mallikarjun C." <cbm@rose.hp.com>, <ips@ece.cmu.edu>    
                                                   cc:       Julian Satran/Haifa/IBM@IBMIL                   
                          16-03-02 21:10           Subject:  RE: iSCSI: Use of the A bit                     
                          Please respond to                                                                  
                          "Rod Harrison"                                                                     
                                                                                                             
                                                                                                             
    
    
    
      >  -----Original Message-----
      >  From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com]
      >  Sent: Saturday, March 16, 2002 4:15 PM
      >  To: Rod Harrison; Mallikarjun C.; ips@ece.cmu.edu
      >  Cc: Julian_Satran@il.ibm.com
      >  Subject: RE: iSCSI: Use of the A bit
      >
      >
      >  I don't know the original reason why TTT was added but
      >  from my perspective,
      >  I never liked the search for ITT (or hash table). So I
      >  thought it was a good
      >  idea.
      >
      >  Now that it has been added we should be able to get rid
      >  of the ITT and that
      >  will solve the problem you have pointed out.
      >
      >  BTW, the problem you pointed out has nothing to do with
      >  the A bit problem
      >  this thread was addressing. But, I'm really glad you
      >  pointed that out! (It
      >  would have been yet another good reason for the TTT).
      >
    
    Since the SCSI status ends the task and therefore the lifetime of the
    initiator task tag the problem I mentioned was specifically caused by
    allowing the A bit to be set with the F bit when there is piggyback
    status. But you are right, the problem was actually always there since
    if the SCSI transfer length was an exact multiple of MaxBurstSize the
    A and F bits would be valid together. In fact I now see there are
    several other ways this combination would be valid.
    
    Anyway, removing the requirement for the initiator to send the ITT in
    the data SNACK solves the problem.
    
      >  If there is debate on what Rod pointed out, we should
      >  probably start another
      >  thread.
      >
      >  Eddy
      >
      >  -----Original Message-----
      >  From: Rod Harrison [mailto:rod.harrison@windriver.com]
      >  Sent: Saturday, March 16, 2002 11:00 AM
      >  To: Eddy Quicksall; Mallikarjun C.; ips@ece.cmu.edu
      >  Cc: Julian_Satran@il.ibm.com
      >  Subject: RE: iSCSI: Use of the A bit
      >
      >
      >
      >          I believe so, but I thought targets were intending to do some
      >  indexing on the ITT? This has always seemed odd to me,
      >  but I thought
      >  it was the case.
      >
      >          - Rod
      >
      >  -----Original Message-----
      >  From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com]
      >  Sent: Saturday, March 16, 2002 3:57 PM
      >  To: Rod Harrison; Mallikarjun C.; ips@ece.cmu.edu
      >  Cc: Julian_Satran@il.ibm.com
      >  Subject: RE: iSCSI: Use of the A bit
      >
      >
      >  The ITT has no good use in a DataACK SNACK and is
      >  residual after we
      >  added
      >  the TTT. It should  probably be "reserved" for DataACK SNACK.
      >
      >  Would that take care of the problem?
      >
      >  Eddy
      >
      >  -----Original Message-----
      >  From: Rod Harrison [mailto:rod.harrison@windriver.com]
      >  Sent: Saturday, March 16, 2002 10:43 AM
      >  To: Eddy Quicksall; Mallikarjun C.; ips@ece.cmu.edu
      >  Cc: Julian_Satran@il.ibm.com
      >  Subject: RE: iSCSI: Use of the A bit
      >
      >
      >  Mallikarjun, Eddy and all,
      >
      >          I think this might be dangerous.
      >
      >          If the initiator receives a DATA-IN with F and A bits
      >  set and a GOOD
      >  SCSI status it would be required to send a data SNACK
      >  PDU containing
      >  an initiator task tag that has "expired" at the initiator.
      >
      >          Initiator task tags are of course reused and there is
      >  no requirement
      >  for the data SNACK to be sent immediately so it would be
      >  possible to
      >  have a single ITT in the network referring to more than 1 task. I
      >  think it is way too late in the game to start
      >  considering conservative
      >  reuse rules for initiator task tags. That could be a potentially
      >  invasive implementation change, especially when you consider that
      >  reusing things is generally a good thing to do from a caching
      >  perspective.
      >
      >          Even if the data SNACK were required to be sent
      >  immediately there is
      >  no guarantee that it would be received by the target
      >  before PDUs for
      >  the task with the reused ITT when there is more than one
      >  connection
      >  per session.
      >
      >          Since the SCSI status ends the task and therefore
      >  releases the ITT
      >  it
      >  seems the only safe way to do this would be to make
      >  piggyback status
      >  mutually exclusive with the A bit in a DATA-IN with the
      >  F bit set.
      >  This would require the target to wait for the data SNACK before
      >  issuing a SCSI status PDU. Clearly this is unpalatable
      >  for latency
      >  reasons.
      >
      >          - Rod
      >
      >  -----Original Message-----
      >  From: owner-ips@ece.cmu.edu
      >  [mailto:owner-ips@ece.cmu.edu]On Behalf Of
      >  Eddy Quicksall
      >  Sent: Saturday, March 16, 2002 12:41 PM
      >  To: Mallikarjun C.; ips@ece.cmu.edu
      >  Cc: Julian_Satran@il.ibm.com
      >  Subject: RE: iSCSI: Use of the A bit
      >
      >
      >  Yes, I agree.
      >
      >  Eddy
      >
      >  -----Original Message-----
      >  From: Mallikarjun C. [mailto:cbm@rose.hp.com]
      >  Sent: Friday, March 15, 2002 11:22 PM
      >  To: ips@ece.cmu.edu
      >  Subject: Re: iSCSI: Use of the A bit
      >
      >
      >  I agree with Julian.
      >
      >  Seems to me that targets should be allowed to ask for an ack
      >  on the last Data-In PDU that concludes the entire
      >  transfer for the
      >  task - a follow-up NOP-ping is needless.  I propose that we
      >
      >  replace:
      >    "it MAY set the A bit to 1 only once every
      >  MaxBurstSize bytes and
      >  MUST NOT
      >  do so more frequently than this."
      >
      >  with:
      >    "it MAY set the A bit to 1 only once every
      >  MaxBurstSize bytes or on
      >  the
      >  last
      >     Data-In PDU that concludes the entire requested
      >  transfer from the
      >  target's
      >     perspective, and MUST NOT do so more frequently than this."
      >  --
      >  Mallikarjun
      >
      >  Mallikarjun Chadalapaka
      >  Networked Storage Architecture
      >  Network Storage Solutions Organization
      >  Hewlett-Packard MS 5668
      >  Roseville CA 95747
      >  cbm@rose.hp.com
      >
      >  ----- Original Message -----
      >  From: "Julian Satran" <Julian_Satran@il.ibm.com>
      >  To: "Paul Koning" <ni1d@arrl.net>
      >  Cc: <Eddy_Quicksall@ivivity.com>; <ips@ece.cmu.edu>;
      >  <owner-ips@ece.cmu.edu>; <rod.harrison@windriver.com>
      >  Sent: Friday, March 15, 2002 11:50 AM
      >  Subject: RE: iSCSI: Use of the A bit
      >
      >
      >  > That could be so but it would be overkill. Status ACK
      >  can implicitly
      >  > acknowledge the last transfer.
      >  > And Yes the fact that the last transfer is not mentioned is an
      >  oversight
      >  > that I will correct.
      >  > This does not mean that you HAVE TO raise the A flag
      >  or that you are
      >  > ENCOURAGED to do so :-)
      >  >
      >  > Julo
      >  >
      >  >
      >  >
      >  >
      >  > Paul Koning <ni1d@arrl.net>
      >  > Sent by: owner-ips@ece.cmu.edu
      >  > 15-03-02 16:09
      >  > Please respond to Paul Koning
      >  >
      >  >
      >  >         To:     Eddy_Quicksall@ivivity.com
      >  >         cc:     rod.harrison@windriver.com, ips@ece.cmu.edu
      >  >         Subject:        RE: iSCSI: Use of the A bit
      >  >
      >  >
      >  >
      >  > >>>>> "Eddy" == Eddy Quicksall
      >  <Eddy_Quicksall@ivivity.com> writes:
      >  >
      >  >  Eddy> I think we may need better explanation about
      >  why some folks
      >  >  Eddy> don't want to do the "positive ack".
      >  >
      >  >  >> We got to this position, since so many folks did
      >  not want to
      >  >  >> support the positive ack.
      >  >
      >  > Something doesn't compute here.
      >  >
      >  > I don't believe the discussion has anything to do with
      >  whether you
      >  > support positive ACK or not.  If you're doing error
      >  recovery level 1
      >  > or above, then you are required to support it, because
      >  the other end
      >  > is allowed to say A=1 and you're required to answer that.
      >  >
      >  > If you don't want to support positive ACK, the solution is to
      >  support
      >  > only error recovery level 0.
      >  >
      >  > The issue under discussion is whether the rule "you
      >  are allowed to
      >  set
      >  > A=1 only once per MaxBurstSize" is correct.  At this point it's
      >  clear
      >  > to me that it is not, because you need to be able to
      >  set A=1 at the
      >  > end of the transfer.  The current rule forbids that
      >  unless the total
      >  > transfer size is >= MaxBurstSize.
      >  >
      >  > Kevin's proposal is a simple fix to this problem.
      >  >
      >  >                   paul
      >  >
      >  >
      >  >
      >  >
    
    
    
    
    
    


Home

Last updated: Mon Mar 18 13:18:16 2002
9179 messages in chronological order