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



    Eddy,
    
    Your colleague is mostly right (I will explain "mostly" below - I meant
    that status follows this last Data-In PDU, but there may still be other
    data transfers).
    
    I reasoned that "concludes the entire requested transfer" is fairly
    clear - since the "entire requested" is Expected Data Transfer Length
    for read commands.  But perhaps it isn't clear, besides I also realized
    that this wording isn't explicit about bidirectional commands.  So, here
    is the next attempt -
    
       "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 read
        data transfer for the task from the target's perspective, and MUST NOT 
        do so more frequently than this."
    
    Note that while a given data PDU may conclude the I/O for the target
    (and so within its rights to set the A-bit, per this wording), the initiator may
    request retransmissions via data SNACK and the target is obligated to 
    satisfy the requests (hence the wording "target's perspective").  
    
    Let us recall that several of us were concerned about too many ACK/SNACKs
    flying back and forth that caused us to place the MaxBurstSize constraint.
    I believe that it's a very reasonable constraint (coupled with the above change), 
    and I would be opposed to leaning towards the flexibility argument at this late stage.
    We need to move on.
    --
    Mallikarjun
    
    Mallikarjun Chadalapaka
    Networked Storage Architecture
    Network Storage Solutions Organization
    Hewlett-Packard MS 5668 
    Roseville CA 95747
    cbm@rose.hp.com
    
    ----- Original Message ----- 
    From: "Eddy Quicksall" <Eddy_Quicksall@ivivity.com>
    To: "Mallikarjun C." <cbm@rose.hp.com>
    Cc: <Julian_Satran@il.ibm.com>; <ips@ece.cmu.edu>
    Sent: Saturday, March 16, 2002 6:50 AM
    Subject: RE: iSCSI: Use of the A bit
    
    
    > It was pointed out to me by a college that when you said "entire requested
    > transfer from the target's perspective" that you meant this transfer would
    > be followed by status.
    > 
    > That is not how I interpreted it. I interpret it as meaning that the target
    > may have additional transfers before the entire transfer from the initiators
    > perspective is finished. And therefore this transfer would may not be
    > followed by status.
    > 
    > Can you please clear that up?
    > 
    > Eddy
    > 
    > -----Original Message-----
    > From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com]
    > Sent: Saturday, March 16, 2002 7:41 AM
    > 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: Sat Mar 16 16:18:09 2002
9160 messages in chronological order