OASIS Key Management Interoperability Protocol (KMIP) TC

Expand all | Collapse all

Groups - Sun 64-bit Binary Alignment Proposal v2 (Sun 64-bit Binary Alignment Proposal.pdf) uploaded

  • 1.  Groups - Sun 64-bit Binary Alignment Proposal v2 (Sun 64-bit Binary Alignment Proposal.pdf) uploaded

    Posted 05-06-2009 14:32
    I've updated the 64-bit alignment proposal to correct a few typos and to
    increase the size of a boolean from 4 to 8 bytes.  You can see changes from
    v1 to v2 in red, and changes from the baseline draft to v1 in blue.
    
    Other 4-byte data types that we may consider expanding to 8 bytes with 4
    leading zeros: Integer, Enumeration, Interval.
    
    So far, the poll shows about half-and-half preference of 32-bit alignment
    vs. 64-bit alignment.  Please note that 64-bit alignment is suitable for
    32-bit processors, whereas 32-bit alignment does not necessarily work
    optimally in 64-bit environments.  Basically, if in doubt, 64-bit alignment
    is more generally useful.
    
     -- Matthew Ball
    
    The document revision named Sun 64-bit Binary Alignment Proposal v2 (Sun
    64-bit Binary Alignment Proposal.pdf) has been submitted by Matthew Ball to
    the OASIS Key Management Interoperability Protocol (KMIP) TC document
    repository.  This document is revision #1 of Sun 64-bit Binary Alignment
    Proposal.pdf.
    
    Document Description:
    This document is a proposal to change the KMIP binary encoding so that it
    is aligned to 64-bit boundaries
    
    Version 2
    
    View Document Details:
    http://www.oasis-open.org/committees/document.php?document_id=32413
    
    Download Document:  
    http://www.oasis-open.org/committees/download.php/32413/Sun%2064-bit%20Binary%20Alignment%20Proposal.pdf
    
    Revision:
    This document is revision #1 of Sun 64-bit Binary Alignment Proposal.pdf. 
    The document details page referenced above will show the complete revision
    history.
    
    
    PLEASE NOTE:  If the above links do not work for you, your email application
    may be breaking the link into two pieces.  You may be able to copy and paste
    the entire link address into the address field of your web browser.
    
    -OASIS Open Administration
    


  • 2.  RE: [kmip] Groups - Sun 64-bit Binary Alignment Proposal v2 (Sun 64-bit Binary Alignment Proposal.pdf) uploaded

    Posted 05-06-2009 15:43
    Matt,
    
    This 64-bit proposal only has a 1-octet type field while the 32-bit
    proposals type field has 4 octets.  I would have thought the 64-bit
    proposal would expand the type field to a 4 octet field to be in
    alignment with the 32-bit proposal.  I think the 64-bit proposal will
    run into scalability problems if the type field only has 256 values as
    others have said.
    
    All,
    
    I won't be on the call tomorrow, so I want to say why I voted for the
    32-bit alignment.  There are many ways to specify this and our goal
    should be to pick the optimal one.  The two options we are considering
    is to optimize the bits on the wire (and thus the bits in storage) with
    the 32-bit alignment or optimize the processor performance for 64-bit
    processors with 64-bit alignment.  
    
    I'm used to 32-bit (or word) alignment in IETF, IEEE, SNIA and FC, so I
    have a propensity to picking what I know and what seems to work well.
    It was probably done this way before 32-bit processors even existed.
    Now that 64-bit processors are coming out, I don't think we should
    change field structures for them.  These new, 64-bit processors should
    be very fast at processing 32-bit fields.  
    
    Do we have any data or understanding as to how fast a 64-bit processor
    would process a 32-bit field vs a 64 bit field? My guess is that this is
    not a big hit on performance.
    
    I would prefer to optimize the bits on the wire and in storage - while
    having plenty of fields.  Padding up to 7 bytes to be two-word aligned
    does not seem to be optimal to me.
    
    In the end, I think the 64-bit field is optimizing the wrong thing.
    Processing power is not the most important parameter to optimize since
    we aren't processing huge volumes of data.  
    
    Please vote for the 32-bit proposal.
    
    Thanks,
    Scott