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

["Scott Kipp" <skipp@Brocade.COM>]

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

-----Original Message-----
From: matthew.ball@sun.com [mailto:matthew.ball@sun.com] 
Sent: Wednesday, May 06, 2009 9:32 AM
To: kmip@lists.oasis-open.org
Subject: [kmip] Groups - Sun 64-bit Binary Alignment Proposal v2 (Sun
64-bit Binary Alignment Proposal.pdf) uploaded

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%20B
inary%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