SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: keys/parameter dependence



    
    --- Robert Snively <rsnively@Brocade.COM> wrote:
    
    > I stand corrected.  If you want to order batches,
    > you must
    > not only transmit the keys that you want to batch,
    > but you must
    > also not transmit another batch of keys until you
    > have received the
    > replies for the outstanding batch.
    
    That's if you don't want to send the next batch
    before hearing something back about the previous.
    If you are happy with the little you did (or didn't)
    receive back), you could just send your next batch
    and consider having ordered them. I.e., there was
    a moment when the other side was allowed to say
    something, so your batches were "ordered"...
    
    > I haven't studied all aspects of this carefully, but
    > I would
    > expect that the processing must proceed on a batch
    > by batch
    > basis, since it is never clear when the
    > Final-Response exchange
    > will be requested and the target must have completed
    > whatever
    > negotiation is going on with respect to previous
    > batch exchanges.
    
    There is no such requirement. If the target likes
    to respond with nothing (or not with everything
    possible) to initiator's first 17 batches and only
    send the missing responses in round (exchange)
    number 18, that's perfectly legal. It is even
    legal to wait for the initiator to set the F-bit
    and only then to start negotiating something else,
    or respond to keys that can be responded to. (A
    correct initiator shouldn't set the F-bit if it
    doesn't have the mandated responses, but it could
    be that it sends a bunch of boolean keys first
    that don't require responses, target answers with
    empty, initiator decides to set the F-bit, target
    decides to send a bunch of responses, etc.)
    Obviously, implementations will likely check
    how many rounds (exchanges) have already taken
    place and not let the negotiations go on forever.
    
    > I would not expect the target to be allowed to hang
    > around doing nothing
    > until Final-Response exchanges were requested.  This
    > seems to be
    > what section 4.4 says, at least for post-login
    > activities.
    
    The target is allowed to. 4.4 just says that it is
    discouraged to reset the F-bit back to 0 while
    sending 0-length data. 
    
    > I was a little surprised to see that post-login
    > negotiations of
    > a parameter a second time without an intervening
    > reset 
    > constitute a protocol error.  Some of the values,
    > notably
    > those duplicating MODE SENSE/SELECT parameters, have
    > traditionally
    > been renegotiable as desired by the SCSI device
    > without an
    > intervening reset, and I would expect that
    > capability to have
    > been mapped into the key=value negotations.
    
    They can be renegotiated, but this has to be after
    a negotiation reset (i.e., after sending
    TTT=0xffffffff), not necessarily after a device reset,
    or in a new negotiation sequence 
    (i.e., new ITT, TTT=0xffffffff). But they can
    be renegotiated as many times as needed on the
    same connection or in the same session.
    
    Martins Krikis, Intel Corp.
    
    Disclaimer: my opinions, not necessarily Intel's.
    
    
    __________________________________________________
    Do You Yahoo!?
    Yahoo! - Official partner of 2002 FIFA World Cup
    http://fifaworldcup.yahoo.com
    


Home

Last updated: Tue Jun 04 16:18:41 2002
10502 messages in chronological order