SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI : EnableACA



    
    
    What you are suggesting is that during reset the target examines all CDBs
    from all initiators.
    Doesn't seem very practical to me.  What about a command in flight (that
    was the first that had a NACA bit)?
    It looks like ED might solve the problem for us making UA behave ACA like.
    
    And EnableACA is not per session (although at a point I intended it to be).
    
    Julo
    
    Santosh Rao <santoshr@cup.hp.com> on 28/04/2001 00:14:59
    
    Please respond to Santosh Rao <santoshr@cup.hp.com>
    
    To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
    cc:   ENDL_TX@computer.org
    Subject:  Re: iSCSI : EnableACA
    
    
    
    
    Ralph Weber wrote:
    >
    > Julian,
    >
    > Regarding your discussion with Santosh...
    >
    > > The task management functions for iSCSI contain a
    > > description the behaviour I am talking about. This
    > > was also subject to a long discussion on the list
    > > that included the need for ACA behaviour for things
    > > like task-set full, busy etc. - not considered for
    > > ACA. For the later T10 is handling making ACA
    > > behaviour available.
    > >
    > My question is... Exactly which what are the cases where
    > T10 is NOT considering making ACA behavior available so
    > that you believe the EnableACA function is necessary in
    > iSCSI?
    >
    > My belief is that every behavior that EnableACA covers
    > but T10 does not needs to be taken to T10 to see if
    > they can find a better way to extend ACA coverage to
    > that area.
    
    Julian,
    
    My original proposal for this issue stated that ANY exception condition
    on an I/O that had the NACA bit set in its control byte of the CDB must
    result in ACA being established.
    
    "Any exception condition" would include :
    - I/O being aborted by the target due to a LU Reset, Target Reset or
    Clear Task Set issued by another initiator.
    - I/O being aborted by the initiator through the use of Abort Task.
    - QUEUE FULL, BUSY, RESERVATION CONFLICT, etc status returned on the
    I/O.
    
    The caveat to this rule is that while ACA is already active, a second
    one would not be established.
    
    The point I'm trying to make is :
    
    1) ACA is being used in this context to aid in the preservation of
    strict command ordering. Any attempt to enforce strict command ordering
    would require initiators to set the NACA bit in the cdb for their I/Os.
    Such initiators would be ACA aware and Clear ACA capable.
    
    The argument that initiators may not be able to perform "Clear ACA" and
    so need an additional control [thru EnableACA] to prevent ACA from being
    established is not applicable, because, such initiators would not set
    NACA in their cdb's, and in that case, ACA would not be established.
    
    2) ACA is a LU level construct and iSCSI is changing this granularity to
    be a session level construct. For example, initiators could turn on ACA
    to only 1 LU on which they had strong ordering requirements.
    
    3) ACA is a ULP construct and any changes, if found necessary, should be
    made in the ULP mode pages and not within iSCSI.
    
    - Santosh
     - santoshr.vcf
    
    
    
    


Home

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