SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI : Command Ordering Proposal.



    Hi Santosh:
    
    See comments below.
    
    > -----Original Message-----
    > From: Santosh Rao [mailto:santoshr@cup.hp.com]
    > Sent: Friday, January 26, 2001 3:17 PM
    > To: Charles Monia
    > Cc: IPS Reflector
    > Subject: Re: iSCSI : Command Ordering Proposal.
    > 
    > 
    > Charles Monia wrote:
    > 
    > >   For example, if I
    > > send commands A B |C| D E, where |C| is ordered, I expect 
    > that D and E won't
    > > complete before |C|.  If A B D and E arrive followed by 
    > |C|, there's no way
    > > to obtain the correct behavior. Incidentally, similar 
    > constraints hold true
    > > for "head of queue" tasks.
    > >
    > 
    > Charles,
    > 
    > SAM-2 Section 7 states :
    > 
    > "The rules for task set management apply only after the task 
    > is entered
    > into the task set."
    > 
    > This implies that the enforcement of the ordering of task 
    > tags in your above
    > example is NOT based on when the initiator sent the commands, 
    > but on when
    > these tasks enter the task set at the target.
    > 
    > i.e. The initiator may send A, B, |C|, D, E, where |C| is ordered.
    > 
    > The commands may arrive at the target in the order :
    > A, E, |C|, B, D in a multi-connection session.
    > 
    > The commands A and E are not subject to any form of ordering.
    > (being simple tag commands and having no ordered tag commands
    > ahead in the task set.)
    > 
    > The commands |C|, B & D are subject to the ordering that B & D cannot
    > be executed until C is first executed. Thereafter, B & D are 
    > subject to
    > simple tag rules.
    > 
    > I believe the confusion lies in whether ordered task tags 
    > imply end-to-end
    > ordering or ordering within the received task set at the 
    > target. the former
    > requires strict ordering on the link or re-ordering at the 
    > target, in the
    > absence
    > of strict link ordering. The latter does NOT require any link 
    > ordering or
    > re-ordering
    > at the target, since it only enforces ordering within the 
    > received task set.
    > 
    > Comments ?
    
    Aside from the fact that the ordering semantics make no sense without this
    property, the initiator's real-world expectation is that end-to-end ordering
    is preserved. Also, as I mentioned earlier, without end-to-end ordering,
    there is a potential for other undesirable side effects due to the
    misordering of task management requests relative to commands in flight.
    
    Charles
    


Home

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