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



    Julian,
    
    	I hadn't seen this explicitly stated in the spec, although thinking
    through the implications of what is said I think it is implicitly in
    there. Perhaps we should spell this out a little more. Clearly when
    processing DATA-IN with F, A bits and GOOD status initiators need to
    be very careful about the order they free the ITT and increment
    expStatSn. Although it seems you are saying the target shouldn't
    consider it an error to receive a command reusing an ITT before it
    sees expStatSn acknowledge status on the original command. Presumably
    the target should consider it an error to see an ITT reused if it
    hasn't issued a status for the task.
    
    	Both SNACK and Command PDUs carry expStatSN so presumably these could
    be used to acknowledge the status. And in the case of the command PDU
    the ITT could be reused in the same PDU that acknowledges the its
    previous status.
    
    	- Rod
    
    -----Original Message-----
    From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    Julian Satran
    Sent: Monday, March 18, 2002 12:45 AM
    To: Rod Harrison
    Cc: Mallikarjun C.; Eddy Quicksall; ips@ece.cmu.edu; Julian Satran
    Subject: RE: iSCSI: Use of the A bit
    
    
    Rod,
    
    If you thought that you can reuse ITT as soon as the status arrived
    you are
    mistaken. There is no need for a conservative reuse rule. The ITT may
    be
    reused only after the task termination (status) has been acknowledged.
    
    However even then on a multiple connection a target may get a new
    command
    with an ITT before status ack.
    In this case a well designed target will avoid sending the status for
    the
    second command before having the first acked.
    
    The data ack (if any) must precede the status ack and the target
    should
    consider the status ack as implying a data ack.
    
    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 17:42           Subject:  RE: iSCSI:
    Use of the A bit
                          Please respond to
                          "Rod Harrison"
    
    
    
    
    
    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 08:18:11 2002
9174 messages in chronological order