SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: Non Spanning key



    
    OK, (note the change of subject.  So we can focus on one thing at a time.)
    
    I am fine with what Mallikarjun said, and do not fine it a problem to do.
    
    I propose that Mallikarjun's approach be our closure.  That is, Keywords
    (including the =) do not span PDUs.
    
    Can I get agreement.
    
    If so we can then move to the next issue.
    
    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSG San Jose Ca
    Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    Home Office (408) 997-6136, Cell: (408) 499-9702
    Internet address: hufferd@us.ibm.com
    
    
    Martins Krikis <mkrikis@yahoo.com>@ece.cmu.edu on 05/24/2002 05:45:09 PM
    
    Sent by:    owner-ips@ece.cmu.edu
    
    
    To:    "Mallikarjun C." <cbm@rose.hp.com>, Julian Satran/Haifa/IBM@IBMIL
    cc:    ips@ece.cmu.edu
    Subject:    Re: iSCSI: Negotiation clarifications still needed
    
    
    
    Mallikarjun wrote:
    
    > 2. Seems to me that we need to stipulate that only
    > key values
    >     may straddle PDU boundaries - key names (ideally
    > inclusive
    >     of "=") shall not.  That should avoid requiring
    > blank PDUs.
    
    Definitely inclusive of "=". Otherwise there are
    no strict guarantees that the whole key has been
    received (we may have keys that are prefixes to
    other keys in future, and vendor keys may be like
    that).
    
    I can implement it and live with it if that's what
    people decide on. I just want people to understand
    that it is conceptually a more complex aproach than
    requiring strictly blank PDUs and having a data-end
    flag. (Even if we don't add a new flag and decide
    data-end by looking for NUL-s at the end, we get
    a cleaner scheme.) Allowing non-blank PDUs  gives
    better bandwith utilization under
    presumably rare circumstances (all pairs not fitting),
    but introduces more complexity for your everyday case.
    
    If we only stipulate that no key ever gets broken,
    then there is the following "clumsiness" required.
    When "originating" a key=value pair, it has to be
    checked whether the key will fit fully in the PDU
    or not, and if not, then "originating" must be
    postponed. We also need either a more elaborate
    state for the key (to mark key as received but
    value as not; so it is not processable yet, nor
    originatable anymore), or for each key=value pair
    being originated, key has to be checked against
    the buffer that would hold the "leftover stuff"
    from the just received PDU, otherwise we may
    illegally originate it. Doable, but not clean.
    
    I still think that letting the whole set-of-pairs
    go through (no matter over how many PDUs spread)
    before the other side is allowed to process them
    is cleanest.
    
    Martins Krikis, Intel Corp.
    
    Disclaimer: these opinions are my own and may
                not be those of my employer
    
    
    
    __________________________________________________
    Do You Yahoo!?
    LAUNCH - Your Yahoo! Music Experience
    http://launch.yahoo.com
    
    
    
    


Home

Last updated: Sun May 26 12:18:53 2002
10328 messages in chronological order